Java lets you create an entirely new subtype of Throwable
, e.g:
public class FlyingPig extends Throwable { ... }
Now, very rarely, I may do something like this:
throw new FlyingPig("Oink!");
and of course elsewhere:
try { ... } catch (FlyingPig porky) { ... }
My questions are:
extends Throwable
?A scenario where I was really tempted to do something like this has the following properties:
Error
, and there's nothing Exception
-al about when it occurs. catch
waiting for it. It will not "slip" past anything. It will not "escape" from any attempt to catch
general Exception
and/or Error
.So perhaps it's clear now what I'm trying to say: FlyingPig
is the result of an exhaustive recursive search.
The object to be searched exists: it's only a matter of finding it in the big sea that is the search space. The search process will be a long one, so the relatively expensive cost of exception handling is negligible. In fact, the traditional control flow construct alternative of using a boolean isFound
flag may be more expensive, because it has to be checked continuously throughout the search process, most likely at every level of the recursion. This check will fail 99.99% of the time, but it's absolutely necessary to propagate the termination condition. In a way, while effective, the check is inefficient!
By simply throw
-ing a FlyingPig
when the sought object is found, you don't have to clutter the code with the management of the boolean isFound
flag. Not only is the code cleaner in that regard, but it may run faster due to this omission.
So to summarize, the choice is between these two:
boolean isFound
, checked continuouslyfalse
true
, you stop recursing and you have to make sure that you can properly unwind to the initial call.FlyingPig
approach boolean isFound
.throw new FlyingPig()
; it's expected, so there will be a catch
for it.boolean
flag, no wasted check if you need to keep going, no bookkeeping to manually unwind the recursion, etc.Questions:
FlyingPig extends Throwable
, or is Exception
just fine? (even though there's nothing exceptional about its circumstances?)If a user wants to create his own, custom throwable, then he/she can extend Throwable class.
Keeping this concept in mind, I would suggest to extend Throwable if you want to throw and/or catch Exception & Error both. Extend Exception if you want to throw and/or catch Exception only. Show activity on this post. Fundamentally you should extends Exception class as you are creating Custom Exception .
junit. Test annotation includes the None class which extends Throwable and is used as the default value for the expected annotation parameter.
You can extends RuntimeException if you need your exception to be unchecked. Because "Throwable" is too non-specific.
I'd say that it is a really bad idea. A lot of code is implemented on the assumption that if you catch Error
and Exception
you have caught all possible exceptions. And most tutorials and textbooks will tell you the same thing. By creating a direct subclass of Throwable
you are potentially creating all sorts of maintenance and interoperability problems.
I can think of no good reason to extend Throwable
. Extend Exception
or RuntimeException
instead.
EDIT - In response to the OP's proposed scenario #1.
Exceptions are a very expensive way of dealing with "normal" flow control. In some cases, we are talking thousands of extra instructions executed to create, throw and catch an exception. If you are going to ignore accepted wisdom and use exceptions for non-exceptional flow control, use an Exception
subtype. Trying to pretend something is an "event" not an "exception" by declaring is as a subtype of Throwable
is not going to achieve anything.
However, it is a mistake to conflate an exception with an error, mistake, wrong, whatever. And there is nothing wrong with representing an "exceptional event that is not an error, mistake, wrong, or whatever" using a subclass of Exception
. The key is that the event should be exceptional; i.e. out of the ordinary, happening very infrequently, ...
In summary, a FlyingPig
may not be an error, but that is no reason not to declare it as a subtype of Exception
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With