Where is the proper place to handle thrown exception from lower layers.. inside the class or at the possible toppest level? OR it depends to the use case?
Where is the proper place to handle thrown exception from lower layers.. inside the
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
You can take a look at this post:
In particular it is now possible (and considered good practice) to set up a top-level exception handler that will handle any unexpected exception on the main thread in a Windows application. This means that it is no longer necessary to have exception handlers in every routine.You may also look at How to implement top level exception handling?
And one link for exception handling in Java http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html
So, as a general answer to your question: I would say that yes it depends on the use case (is it just your simple short script or a full-fledged application), but you should try to do the exception handling at the highest possible level, and while doing that do keep in mind the “technicality” of the message you present to your users (trust me, a message “error 31231241 in main thread” doesn’t improve user friendlines of your application).
edit:
As Steve McConnell also states in his famous Code Complete 2 book, one should
Throw exceptions on the right level of abstraction - for example if you have a getUser() method and you return IOException then that would be very bad.But yes, I think that’s commmon sense. Also, he says that one should write a function in such manner that if some other function sends it “garbage”, it should not cause a crash of the whole program.Also, he is in favor of using assertions, and he says:
Use error handling code for the conditions you expect to occur; use assertions for conditions that should never occur.Finally, the states that while addressing the errors you should keep in mind the two approaches:
robustnessandcorrectness. The story he tells in the book for this example is very vivid and stayed in my head long after I’ve read it. Consider having a “Text editing application” and take into account the correctness of the data presented. Imagine few pixels “go wild” (you misscalculate them, or sth like that) – for sure you wouldn’t consider to force close the application if something like that happens and this is called robustness (continue operating). But, imagine now that you’re making an X-ray manipulation application- in this case any “wierd data” should (as McConnell suggest) cause the critical error message and it is said that you’re striving for correctness in your applicaiton.P.S. pardon for the CC2 part, but I just love that book and think every developer should read it (at least once).