Comments on: Exception handling revisited http://www.magpiebrain.com/blog/2005/04/05/exception-handling-revisited/ Sam Newman's blog Fri, 21 Nov 2008 20:12:19 +0000 http://wordpress.org/?v=2.6.3 By: sam newman http://www.magpiebrain.com/blog/2005/04/05/exception-handling-revisited/#comment-658 sam newman Sun, 10 Apr 2005 21:20:03 +0000 http://www.magpiebrain.com/2005/04/05/exception-handling-revisited/#comment-658 Yes, you are maing that assumption - and that is one of the problems I had with this approach, especially if you aren't the person whose going to be doing the calling. The way I think of it, is that I use checked exceptions within an application statck, but never throw a checked exception out of the boundry of the application. I have complete control over the stack, therefore know what error conditions can be handled. It's not a one-size fits all approach however - for example what happens if you call the same class in two different contexts? In one you can handle the error, in the other you can't. That said for 99% of code, exception handling has become a no-brainer, and has resulted in simpler, cleaner error handling. Yes, you are maing that assumption - and that is one of the problems I had with this approach, especially if you aren’t the person whose going to be doing the calling.

The way I think of it, is that I use checked exceptions within an application statck, but never throw a checked exception out of the boundry of the application. I have complete control over the stack, therefore know what error conditions can be handled. It’s not a one-size fits all approach however - for example what happens if you call the same class in two different contexts? In one you can handle the error, in the other you can’t. That said for 99% of code, exception handling has become a no-brainer, and has resulted in simpler, cleaner error handling.

]]> By: Tim http://www.magpiebrain.com/blog/2005/04/05/exception-handling-revisited/#comment-657 Tim Sun, 10 Apr 2005 21:11:50 +0000 http://www.magpiebrain.com/2005/04/05/exception-handling-revisited/#comment-657 Hey Sam, aren't you making assumptions about what the caller can and cannot handle within the throwing class? I mean, why does the pitcher care what the catcher can handle? What if you get a new catcher that can't handle your checked exceptions or someone who can handle your runtime exceptions? Is there a good rule of thumb for knowing when your caller should be able to handle an exception and when to throw an unchecked exception? Hey Sam, aren’t you making assumptions about what the caller can and cannot handle within the throwing class? I mean, why does the pitcher care what the catcher can handle? What if you get a new catcher that can’t handle your checked exceptions or someone who can handle your runtime exceptions?

Is there a good rule of thumb for knowing when your caller should be able to handle an exception and when to throw an unchecked exception?

]]>