Why is there a specific RuntimeException for the project?

Question

Is there any point in com.myco.myproj.MyProjRuntimeException that completeley extends a RuntimeException?

Answer 1

Yes. Throw unchecked exceptions and subclass them.

There is a lot of talk about whether checked exceptions are really good. In short, if I chose a checked exception, is my client really relevant?

Unchecked exceptions are a good way to notify your clients of exceptional situations (including illegal preconditions) and yet not burden them with the need to wrap calls in your API with try-catch blocks, which for the most part mostly serve no purpose except debugging, tracking, etc.

So why not throw a RuntimeException ? It is not elegant, and it is less readable. Make this your own exception that arises from it, even if for some reason it is not more specific when it throws an exception.

Answer 2

It depends on whether you want to handle the exception condition differently than other exceptions, beyond the call stack. If you intend to catch and handle the exception, I would recommend creating a custom type. This makes code and clean catch articles clearer. If you don't catch the exception, then there is probably no reason to create a new type.

Answer 3

Not really. The additional information that you receive from the presence of the exception name displayed in the stack trace can be set by simply setting the message line of the standard RuntimeException . However (think about it), it may be useful for a subclass of RuntimeException simply add a special line to any message.

I try to make only checked exceptions; as a rule, standard unchecked exceptions already cover enough potential cases.

Answer 4

Good style to maintain your own hierarchy of exceptions.

But I saw only a few people who can use this technique with real profit.

Answer 5

in Effective Java, Joshua Bloch writes:

Use runtime exceptions to indicate programming errors. The vast majority of runtime exceptions indicate precondition violations.

However, you can use this exception at runtime as the base class for the hierarchy of runtime exceptions used in your project. Thus, errors become more clear and traceable.

Answer 6

Many people (me and C # developers are included) believe that checked exceptions are an unsuccessful language experiment and shun them. Then creating your own exception hierarchy in RuntimeException is an obvious step.

Answer 7

In my opinion, you should only create new exceptions if you really need to, i.e. they want to catch them and make a specific appeal for them. In all other cases, I really don't see the utility.

Answer 8

Rod Jonhson wrote about this one-on-one in the design and development of J2EE Expert, and, like Tom, RuntimeException should be used to program errors. A good example is SQLException, a lower-level access API should catch them and throw its own "SQLRuntimeException", since most of the time the call code cannot do anything with an exception. Thus, your higher-level apis will not force you to catch or transfer lower-level exceptions to your signature, which makes the code simpler and more focused on the business domain.

Answer 9

Subclass exceptions based on how they are processed, not those who wrote them ...

Typically, a runtime exception cannot be handled in any other way than by reporting an error and possibly displaying an error message.

Checked exceptions may have a specific reserve, in which case they should not subclass "MyFrameWorkException" - as in this case, catching an exception MyFrameWorkException will not do more than a general catch (registration, etc.)

It is a pretty bad practice to come up with a whole hyarochia of exceptions that have little in common, except for the fact that they belong to a certain structure. (It is assumed that packages are used for exactly this.)

This is normal for a subclass of RuntimeException (if existing subclasses do not match god)

Unhandled document exceptions. Be conservative with checked exceptions and don't create hierarchies.