Why have a project specific RuntimeException?

Question

Is there any point in having a com.myco.myproj.MyProjRuntimeException, which completley extends RuntimeException?

Answer 1

Not really. The extra information you get from having the exception name show up in a stack trace could be given by simply setting the message string of a standard RuntimeException. However (come to think of it), it might be useful to subclass RuntimeException simply to prepend a custom string onto any message.

I tend to only make custom checked exceptions; generally, the standard unchecked exceptions cover enough potential cases already.

Answer 2

It's a good style to maintain your own exceptions ierarchy.

But I've seen just a few people who can use this technique with real profit.

Answer 3

in Effective Java, Joshua Bloch writes:

Use run-time exceptions to indicate programming errors. The great majority of run-time exceptions indicate precondition violations.

That being said, you could use that run-time exception as a base class for a hierarchy of run-time exceptions, used in your project. That way, errors become more legible and traceable.

Answer 4

It depends on if you want to handle the exceptional condition differently than other exceptions farther up the call stack. If you intend to catch and handle the exception, then I'd recommend creating the custom type. It makes for more legible code and cleaner catch clauses. If you're not going to catch the exception, then there's probably little reason to create a new type.

Answer 5

Many people (me and the designers of C# included) believe that checked exceptions are a failed language experiment and avoid them. Then, creating your own exception hierarchy under RuntimeException is an obvious step.

Answer 6

Yes. Do throw unchecked exceptions, and subclass them.

There is much talk about whether checked exceptions are really any good. In a nutshell, if I throw a checked exception, does my client really have anything to do with with it?

Unchecked exceptions are a good way to notify your clients about exceptional situations (including illegal pre-conditions), and yet not burdening them with the need to wrap calls to your API with try-catch blocks, which most of the time basically serve no purpose, other than debugging, tracing, etc.

So why not throw a RuntimeException? It's not elegant, and it's less readable. Make it your own exception which derives from it, even if it's for no reason other than being more specific when throwing the exception.

Answer 7

Rod Jonhson wrote on this in Expert one-on-one J2EE design and development and as in Tom's answer RuntimeException should be used for programming errors. A good example is SQLException, lower level data access API should catch them and throw your own "SQLRuntimeException" as most of the time the calling code cannot do anything with the exception. This way, your higher level apis are not forced to catch or carry lower level exceptions in their signature, which make code simpler and more focused on the business domain.

Answer 8

Subclass exceptions based on how they are handled rather than who wrote them...

Normally runtime exception can't be handled in another way than logging the error and possibly display an error message.

Checked exceptions might possibly have a specific fallback, and in that case they should probly not subclass a "MyFrameWorkException" - as in that case, catching a MyFrameWorkException would not do more than the generic catch (logging etc.)

It is a rather bad practice to invent a whole hiearachy of exceptions that does have little in common except the fact that they belong to a particular framework. (packages are supposedly used for just that.)

It is perfectly ok to subclass RuntimeException (if the existing subclasses are not a god fit)

Document unchecked exceptions. Be conservative with checked exceptions, and don't build hierarchies.

Answer 9

In my opinion, you should only create new Exceptions if you really need them, i.e. want to catch them and do a specific treatment on them. On all other cases, I don't really see the usefulness.