4 ms·
I don't think it's dangerous at all. What's the difference between an empty, non-nil map and a nil map? Why should their behavior differ? The fact that a map
by NateDad 12y ago
I don't think it's dangerous at all. What's the difference between an empty, non-nil map and a nil map? Why should their behavior differ? The fact that a map can be nil is effectively like an implementation detail. You asked for the value by a key, and the map tells you that key doesn't exist. Why should a map not having a value in it cause an exception? It's not exactly a rare occurrence. go supports this with the two value return, with the second value telling you if the key existed.
- ajuc 12y ago> Why should a map not having a value in it cause an exception? map controlCenters = database.getControlCenters(); // returns map column->value, nil if no connection int controlCentersInExistence = controlCenters["count"]; //FIXME - use the other syntax, I forgot how it looked like if (controlCentersInExistence == 0) { // someone nuked USA! WW3Manager.launchMissiles(); // we need to retaliate! }
- NateDad 12y agoSee, 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?