I consider the tendency to "handle where the exception happens" to be a Checked Exception caused anti-pattern. The intent of "handle where the exception happens" usually results in the opposite of it's intent. It tends to mask/hide errors and leave the application in a bad state (bad data integrity for example).
Not that it's NEVER valid, but it usually isn't. The sorts of things that cause exceptions can't usually be handled - most of them occur because of bugs or system failures. And most apps simply won't work correctly if your database is down, they can't hit a web service, sql insert fails, file is missing/can be saved.... So IMO the best general pattern is to let the exception bubble up to the top level thread and log/display/notify the user. Note that log/display/notify the user is very much not "throw and forget". There are cases where you can gracefully handle of course, but I've found these to be less than 10% of exception cases. This is the pattern that is common in all other languages without checked exceptions. You default to letting them bubble/handle at the top, and if you identify a case where the application can/should handle then you put code in for that. On Thu, Mar 24, 2011 at 3:16 AM, Phil <[email protected]> wrote: > Checked or unchecked aside, one reason I like the separation between > the old C-style return value approach and exceptions is that an > exception is a clear statement that something very much out of the > ordinary has happened, something that the higher level business logic > is not expected to handle. > > This clean separation has a cleansing effect on the code as well as > making it easier to look at unfamiliar code and separate business > logic from exception handling. > > Personally I sit in the 'handle it immediately or wrap and throw' > camp. Not least because the most realistic place to handle the > exception is inside the method that it occurred. The further away from > the exception the handling code resides, the harder it becomes to code > a specific recovery action. So as a rule of thumb my classes will not > throw exceptions. If exceptions play an important part in the overall > component (for example in some kind of remote interface/adapter where > an exception will manifest if the thing on the other side is broken/ > uncontactable) then this would be presented to the outside world as a > state change event (e.g. connection lost) rather than as an exception. > > There are plenty valid scenarios where exceptions should be caught and > handled, applying a blanket rule 'throw and forget' is almost as bad > as 'catch(Throwable t) {}' and indicates a weakness in the software > architecture. > > On Mar 24, 7:57 am, Russel Winder <[email protected]> wrote: > > On Thu, 2011-03-24 at 00:34 +0000, Kevin Wright wrote: > > > It's quite simple... If there's something that can happen in your > > > method, and the caller *explicitly* needs to deal with it, then > > > there's a technique for dealing with that... It's commonly known as a > > > "return value". Yes, some form of "Maybe" or "Either" type combined > > > with lambdas makes this sort of thing a lot more concise and readable, > > > but it's certainly doable in Java, and the language isn't exactly a > > > stranger to boilerplate and verbosity! > > > > Which is, I believe, why the Go folk have eschewed exceptions in favour > > of return codes. They solve the problem C has with this by using > > multiple return values -- which avoids having to find obscure out of > > band information channels or usurping the domain to carve out an error > > information channel. > > > > value , errorCode = someOperationThatReturnsAValueAndAnErrorCode > ( ) > > if ( errorIndicated ( errorCode ) ) { > > processError ( errorCode ) > > } else { > > processSuccess ( value ) > > } > > > > Seems to be the idiomatic Go way of doing things. A return to a better > > way or just backward looking? > > > > -- > > Russel. > > > ============================================================================= > > Dr Russel Winder t: +44 20 7585 2200 voip: > sip:[email protected] > > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > > London SW11 1EN, UK w:www.russel.org.uk skype: russel_winder > > > > signature.asc > > < 1KViewDownload > > -- > 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. > > -- 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.
