4

When creating a user defined exception What is the best practice, should the exception be created as checked or unchecked ?

I know unchecked/runtime exceptions need not be handled in the code.

Pankaj
  • 14,638
  • 3
  • 17
  • 23

3 Answers3

9

If the exception is recoverable - it should be checked. If the exception is not recoverable and the program must halt - it should be unchecked.

A good summary about checked vs. unchecked exceptions can be found here.

Nir Alfasi
  • 53,191
  • 11
  • 86
  • 129
1

Here is a snippet of my answer from another post:

The custom exception should extends RuntimeException if you want to make it unchecked else extend it with Exception.

With unchecked exceptions calling code method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.

As the calling method may not handle RuntimeException, one needs to be careful while throwing RuntimeException.

Link to the complete answer : Extending Exception/RunTimeException in java?

Community
  • 1
  • 1
Ankur Shanbhag
  • 7,746
  • 2
  • 28
  • 38
1

Personally, I find the checked exception mechanism of Java to be burdensome.

While the distinction between recoverable and unrecoverable errors is valuable, there does not always seem to be a one-to-one mapping of a particular exception instance and the recoverability of its associated error, eg. not all IOExceptions are always recoverable.

The semantics that describe checked and unchecked exceptions are similarly murky. Even in the Java Platform libraries there does not always appear to be a consistent interpretation of these semantics. For example, exceptions generated in the JDBC platform library are checked; whereas exceptions generated in the JPA 2.0 API are unchecked.

More useful semantics may be the following:

  • when you wish to -force- the user of your API to respond to an exception that your library is generating, then define a checked exception. Usually this occurs when the exception must force the client to do something that is both different and important to do. This is a very valid use of the checked exception mechanism which becomes a part of the contract specified by your exported API.

  • when you wish to leave the user of your API free to decide for himself whether to handle your exception himself or to allow the exception to go unhandled, then throw an unchecked exception.

Especially if you are not creating an API to be exported in a library that you intend to distribute, the provided standard runtime exceptions are usually adequate for most purposes:

  • NullPointerException
  • IllegalArgumentException
  • IllegalStateException
scottb
  • 9,908
  • 3
  • 40
  • 56
  • "not all IOExceptions are always recoverable" - this is exactly the reason it's checked. When such an error is not recoverable the developer can catch it and throw an unchecked exception instead. Had it been implemented as 'unchecked' - it would be more difficult to handle the cases where the exception *is* recoverable. – Nir Alfasi Aug 03 '15 at 01:23
  • @alfasin: it's just murky. I'm not sure the checked exception mechanism was the right approach to bring order to this programming challenge. "Not all IOExceptions are always recoverable ... and ... not all IllegalArgumentExceptions are always unrecoverable". Preconditions can be tested to guard against either. But when you choose a checked exception, you force users of your code to do something whether they want to or not. – scottb Aug 03 '15 at 01:28
  • "when you choose a checked exception, you force users of your code to do something whether they want to or not" - true! that's why, when you write an API that will be used by *other* users, you should be mindful of this fact and not abuse the mechanism of throwing exceptions. In general, it's a good practice to handle exceptions in the lowest possible level. By doing so, you'll expose only the exceptions that you cannot handle to your users. – Nir Alfasi Aug 03 '15 at 01:42
  • Again, as long as you don't "abuse" this mechanism, following these guidelines empower your users: you are giving them the option to handle it if they choose to do so. In case they decide not to do so, they can convert the checked exception to an unchecked one, and halt the program. I wouldn't call it "murky", but I would say that it forces *you* to think, and then re-think, before you make such a decision. And IMO - that's not such a bad thing ;) – Nir Alfasi Aug 03 '15 at 01:45