4 ms·
See, that's not a problem of the map, that's a problem of poor error handling. If for some reason database.ControlCenters() could ever not return a valid map,
by NateDad 12y ago
See, that's not a problem of the map, that's a problem of poor error handling. If for some reason database.ControlCenters() could ever not return a valid map, it would also return an error value.
controlCenters, err := database.getControlCenters()
if err != nil {
return fmt.Errorf("couldn't get map of control centers: %v", err)
}
// now we know controlCenters is valid.
controlCentersInExistence, ok := controlCenters["count"]
if !ok {
return errors.New("no count of control centers!")
}
// now we know the column existed
if controlCentersInExistence == 0 {
WW3Manager.launchMissiles()
}
Go's conventions are actually excellent at making this code MUCH more robust.
- ajuc 12y agoYes obviously it's bad code, but it's bad code that's easier to write, than good code. That's dangerous. That's why Python does it better IMHO. BTW err != nil? I don't know, it seem fragile. Maybe it's years of exception indoctrination speaking, but I am scared that someone will return false for errors and someone else will check err != nil, or the reverse, or some other misunderstanding, and it will fail.
- NateDad 12y agoFalse is not a valid value for an error... Welcome to static typing ;). It's either nil or some valid error.
- Dewie 12y ago> False is not a valid value for an error... Welcome to static typing ;). I'm confused. Previously you gave this example: a, ok := m[1] // returns 0, false Which means that `ok == false`. But how can it be false if that is not a valid value for an error?
- NateDad 12y agoSorry to be confusing and/or confused. Map access in Go returns value, boolean where the boolean indicates if the key existed in the map. This is in contrast to most functions which can fail with a generic "error" value. So, for errors, nil means no errors. For map access, false means it didn't exist in the map. About your original point about someone returning "the wrong thing" in an error... there's really no misunderstanding possible. Because Go is statically typed, the ONLY things you can return for an error are nil (no error), or something that fulfills the error interface (a type with a method Error() that returns a string). You can't return false, or 0, or "" when the code expects you to return an error... the compiler won't let you. This is how all error handling works in Go. From the most basic program you write, you learn that err == nil means success, anything else means failure. Does that help any?