I'm reading and learning from Sierra/Bates... Stumbled upon the section "Rethrowing the Same Exception". This one left me fuzzy. I do understand the mechanics of it; but why would we want to do it (rethrow the same exception)? I accept the abstract explanation such as the one in the book:
But if that's the case, then why did we even bother to try to catch it at all rather than simply pass the buck? What is the right, good practice code design approach here?
If there is a relatively simple, concrete example of such behavior (suitable for SCJP level), I would appreciate seeing a little piece of code. I'm trying to see this SCJP preparation in practical light too (if that's possible, and I hope it is )...
Cheers, Marcus [ November 20, 2007: Message edited by: Marcus Jastrebowski ]
Let me start with a general comment about exception handling. The whole purpose of having an exception handling system is to allow each error to bubble up easily to a level where handling it is most appropriate, since the immediate caller of an exception-throwing method often resides at too low a level of abstraction to handle the error properly in the context of the overall application.
Now, remember that exception classes are full-fledged classes in themselves, which means that you can define instance variables and methods. These may tell you more information about the cause of the error than what you can tell from just knowing the exception class. Thus, it's actually fairly common to catch an exception, call one of its methods to learn more about the cause, and then use that information to decide whether you can reasonably handle that condition at your level. If not, then you'd re-throw the exception.
For example, I believe J2EE has some HTTPException class (in some package I don't recall off-hand) that has a getStatusCode() method. You might therefore quite reasonably write code that looks like this:
Most of the simple exceptions just use the class itself to denote a specific error condition, so you probably won't need to do this for those exception types. But in some cases it wouldn't make sense to create a new specialization for every possible error cause (do you really want HTTP400Exception, HTTP401Exception, HTTP402Exception, ....?), so that's when you'd use the above construct.
Another possible use case I can think of would be if you want to log exceptions without handling them, i.e. although admittedly I've never had to do something like this so far.
posted 12 years ago
Thanks Kelvin, this is a great reply, and just what I needed to get a better view of the whole exception concept. I am new here, but you have already helped me out a few times out of some tricky problems. And I can see your name popping up many places in my searches throughout this board. We owe you man!
I guess for me, the stumbling blocks usually happen when I start asking myself the question of *why*, not the question of *how*. The *how* is very well explained in the K&B book, the *why* ... well, that is not exactly the point of that book, is it. (I am talking here about *why* of best practices, designs, patterns, etc.)
I have some knowledge of Java (and further expanding quickly), but what I am beginning to think about more and more is the way to use it properly. As I learn, I can see that Java is such a powerful tool that in the wrong hands all that magic can become a bit of a risk or danger to an unaware user, or abuser, of the language power. SCJP exam tests on some things that you should never do -- like how not to abuse the assertion mechanism, for example. So that's fine. But obviously there are so many other things that should not be abused and that's outside the book's scope.
In that light, I was thinking yesterday about the exception rethrowing. In general, the exception mechanism is an incredible invention, and whoever invented it should get a medal of unknown developer honor. And then I was thinking about a potential for an abuse (or bad design), but based on your explanation, I can see that it should not be a problem indeed.
It all boils down to where the exception would 'best' be handled. Say for example that you have a big project and a whole team of developers have decided that ALL exceptions need to be handled by the company's MyCompanyExceptionHandlerHelper class (forgive the long name LOL) For what ever reason (standardized handling of all exceptions or whatever). Now say you're working on an implementation of some detailed class that does something specific and it may throw several different types of exceptions. Rather then handle the exception at that low level, you may want to 'propogate' (pass the buck or let it bubble up the call stack...however you want to think of this). Therefore, you'd throw the exception, and perhaps the calling class/object may want to 'rethrow' the exception so that the MyCompanyExceptionHandlerHelper class deals with it. I actually remember working at an outsourcing company where every developer at the company was told (in a meeting) "DO NOT JUST do e.printStackTrace() for this project! We want everyone using the 'such and such' for handling exceptions so throw or rethrow any exceptions you encounter in your code".
Analogy: It's like owning a boxing gym and you say, look you can come here and train and spar, but you have to sign this waiver because if you get your jaw broken, we don't fix broken jaws, that's the job of a doctor! Hmm, not sure if this is the greatest analogy, but the idea is sort of the same, a Boxer object comes into your BoxingGym and getsInjured() which throws an InjuryException...an ojbect of type Trainer doesn't want to handle this, some sort of Doctor object or Hospital object should deal with this! So if the trainerObject will appropriately throw new InjuryException and let it gets handed to the appropriate handler (in this case the doctor) Does this help clarify it? I hope so
[ November 22, 2007: Message edited by: nico dotti ] [ November 22, 2007: Message edited by: nico dotti ]