Posted Mar 31, 2012 23:33 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
In reply to: Uses by cmccabe
Parent article: Go version 1 released
Well, checked exceptions are a failed idea for many reasons.
First, having an exact exception type in a function signature is BAD. That means that you are expecting these exceptions to be thrown sometime and this means you are most probably better off using return codes in this case.
C++ has a better idea - exception guarantees ( http://en.wikipedia.org/wiki/Exception_guarantees ). I rarely care about types of exceptions but I really care about the fact that exceptions can occur at all. Having a type system enforcing correct exception safety would be really nice.
C++ moves in this direction, but slowly.
>A final comment. If you design the system such that there are a lot of corner cases are tricky situations, then yes, your code will be tricky. On the other hand, if you design the system such that it's simple, you won't feel the need for complexity. For example, you could load the entire configuration at once and keep it in memory, eliminating the need to handle the "file not found" error condition that you're so worried about.
How about lazy-loading of entities from database or memcached? Or maybe a failure to perform action because there's not enough space for audit log entry? There are lots of cases where exceptions can happen.
Callbacks are another case - what happens if a callback encounters an error?
>Exceptions don't reduce the complexity of code. At best, they just sweep it under the rug. And that's not a good thing, for anyone concerned.
Nope. Exceptions help to deal with a thorny problem - non local effects of errors.
>Google coding standards for C++ dictate no use of exceptions-- ever. I think the way Go handles exceptions is the right way.
Google doesn't use exceptions because of legacy. They have a lot of exception-unsafe code and it's just too complex to convert it.