Extending Throwable in Java

Question

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:

• Is this a bad idea? And if so, why?
  • What could've been done to prevent this subtyping if it is a bad idea?
  • Since it's not preventable (as far as I know), what catastrophies could result?
• If this isn't such a bad idea, why not?
  • How can you make something useful out of the fact that you can extends Throwable?

---

Proposed scenario #1

A scenario where I was really tempted to do something like this has the following properties:

• The "event" is something that will happen eventually. It is expected. It most definitely is not an Error, and there's nothing Exception-al about when it occurs.
  • Because it is expected, there will be a catch waiting for it. It will not "slip" past anything. It will not "escape" from any attempt to catch general Exception and/or Error.
• The "event" happens extremely rarely.
• When it happens, usually there's a deep stack trace.

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:

• Traditional control-flow approach
  • Use a boolean isFound, checked continuously
  • 99.99% of the time, the check is a "waste", because it'd still be false
  • When it eventually becomes true, you stop recursing and you have to make sure that you can properly unwind to the initial call.
• FlyingPig approach
  • Don't bother with any boolean isFound.
  • If found, just throw new FlyingPig(); it's expected, so there will be a catch for it.
  • No management of boolean flag, no wasted check if you need to keep going, no bookkeeping to manually unwind the recursion, etc.

Questions:

• Is this technique of (ab)using exception valid? (Is there a name for it?)
• If valid, should FlyingPig extends Throwable, or is Exception just fine? (even though there's nothing exceptional about its circumstances?)

Answer 1

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.