> I take the point that it is possible to make code harder to read using > exceptions in a way that is not possible without. I must admit I didn't > really think it through when I read Joel's blog post.
Joel seems to think of exceptions as mere alternative return points and in that goto light, he has a point. However exceptions are meant to be used for exceptional cases and not a replacement for proper factored condition checking down the primary path. Another problem with Joel's view is that of context, if you can only signal an error code, you'll have to resort to some shared/mutable place for further context. > There is the opposite danger, though: ignoring a return value. Since > C-like languages allow functions to be called as statements, it is > pretty easy to just ignore the fact that there is an error code > returned. Checked exceptions force you to deal with the issue. Well they force you to acknowledge them, but they don't really do anything else and as such can provide a false sense of security (can be swallowed or logged). At least with a non-checked, an unhandled problem would just bubble up to the surface and be trapped in some high-level place around the message pump. /Casper --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
