When to choose checked and unchecked exceptions

Question

In Java (or any other language with checked exceptions), when creating your own exception class, how do you decide whether it should be checked or unchecked?

My instinct is to say that a checked exception would be called for in cases where the caller might be able to recover in some productive way, where as an unchecked exception would be more for unrecoverable cases, but I'd be interested in other's thoughts.

Remittance

Barry Ruzek has written an excellent guide about choosing checked or unchecked exceptions. – Weak

Answer 1

Checked Exceptions are great, so long as you understand when they should be used. The Java core API fails to follow these rules for SQLException (and sometimes for IOException) which is why they are so terrible.

Checked Exceptions should be used for predictable, but unpreventable errors that are reasonable to recover from.

Unchecked Exceptions should be used for everything else.

I'll break this down for you, because most people misunderstand what this means.

1. Predictable but unpreventable: The caller did everything within their power to validate the input parameters, but some condition outside their control has caused the operation to fail. For example, you try reading a file but someone deletes it between the time you check if it exists and the time the read operation begins. By declaring a checked exception, you are telling the caller to anticipate this failure.
2. Reasonable to recover from: There is no point telling callers to anticipate exceptions that they cannot recover from. If a user attempts to read from an non-existing file, the caller can prompt them for a new filename. On the other hand, if the method fails due to a programming bug (invalid method arguments or buggy method implementation) there is nothing the application can do to fix the problem in mid-execution. The best it can do is log the problem and wait for the developer to fix it at a later time.

Unless the exception you are throwing meets all of the above conditions it should use an Unchecked Exception.

Reevaluate at every level: Sometimes the method catching the checked exception isn't the right place to handle the error. In that case, consider what is reasonable for your own callers. If the exception is predictable, unpreventable and reasonable for them to recover from then you should throw a checked exception yourself. If not, you should wrap the exception in an unchecked exception. If you follow this rule you will find yourself converting checked exceptions to unchecked exceptions and vice versa depending on what layer you are in.

For both checked and unchecked exceptions, use the right abstraction level. For example, a code repository with two different implementations (database and filesystem) should avoid exposing implementation-specific details by throwing SQLException or IOException. Instead, it should wrap the exception in an abstraction that spans all implementations (e.g. RepositoryException).

Surra

"you try reading a file but someone deletes it between the time you check if it exists and the time the read operation begins." => How is this even 'expected'? To me it sounds more like: UNexpected and preventable.. Who would expect a file to be deleted just between 2 statements? – Checkroom

@KorayTugay Expected doesn't mean that the scenario is typical. It just means that we can foresee this error occurring ahead of time (compared with programming errors which cannot be predicted ahead of time). Unpreventable refers to the fact that there is nothing that the programmer can do to prevent the user or other applications from deleting a file between the time that we check whether it exists and the time the read operation begins. – Surra

So any database-related issues within the method must throw checked exception? – Amoebic

Only if the user of the method expects the method to be database-related. If you have a Point::getX()-method, it might be unexpected that you look it up in a database; Also unexpected that the Point might not have an X-value. Define the interface first and think - implementation independent - what might go wrong. – Wheeled

you said how , but nothing about why. – Inevitable

@Inevitable The question doesn't ask why. My opinion is that checked exceptions are the result of Java's culture of strong-typing. We want to catch as many errors as possible at compile-time, as opposed to blowing up at runtime as Javascript does. For the small subset of exceptional cases that are predictable and preventable we want users to "check off a list" and make a conscience decision of how they want to handle each one. – Surra

Answer 2

From A Java Learner:

When an exception occurs, you have to either catch and handle the exception, or tell compiler that you can't handle it by declaring that your method throws that exception, then the code that uses your method will have to handle that exception (even it also may choose to declare that it throws the exception if it can't handle it).

Compiler will check that we have done one of the two things (catch, or declare). So these are called Checked exceptions. But Errors, and Runtime Exceptions are not checked for by compiler (even though you can choose to catch, or declare, it is not required). So, these two are called Unchecked exceptions.

Errors are used to represent those conditions which occur outside the application, such as crash of the system. Runtime exceptions are usually occur by fault in the application logic. You can't do anything in these situations. When runtime exception occur, you have to re-write your program code. So, these are not checked by compiler. These runtime exceptions will uncover in development, and testing period. Then we have to refactor our code to remove these errors.

Knightly

That's the orthodox view. But there's a lot of controversy about it. – Nitroparaffin

Answer 3

The rule I use is: never use unchecked exceptions! (or when you don't see any way around it)

There’s a case for the opposite: never use checked exceptions. I’m reluctant to take sides in the debate (there’s definitely good arguments on both sides!) but a fair number of experts feel that checked exceptions were a wrong decision in hindsight.

For some discussion, check the WikiWikiWeb’s “Checked exceptions are of dubious value”. Another example of an early, extensive argument is Rod Waldhoff’s blog post.

Description

IMHO, checked exceptions could have been a major asset if there had been an easy way for a method to declare that it is not expecting methods called in a particular block of code to throw certain exceptions (or any at all), and that any checked exceptions which are thrown contrary to such expectation should be wrapped in some other exception type and rethrown. I'd posit that 90% of the time when code isn't prepared to cope with a checked exception, such wrap-and-rethrow would be the best way to handle it, but because there's no language support it's seldom done. – Newcomer

@Newcomer Essentially that’s it: I’m a die-hard fan of strict type checking and checked exceptions are a logical extension of that. I have completely abandoned checked exceptions even though I conceptually like them a lot. – Description

One peeve I have with the design of exceptions, which the mechanism I described would solve, is that if foo is documented as throwing barException when reading past the end of a file, and foo calls a method which throws barException even though foo isn't expecting it to, the code which calls foo will think the end of the file was reached, and will have no clue that something unexpected happened. I'd consider that situation as being the one where checked exceptions should be most useful, but it's also the only case where the compiler will allow unhandled checked exceptions. – Newcomer

@supercat: There is already an easy way for code to do what you want in the first comment: wrap the code in a try block, catch Exception, and wrap the Exception in a RuntimeException and rethrow. – Terryterrye

@WarrenDew I’m confident that Supercat is aware of this method and deems it lacking due to the resulting code bloat. Having a declarative style of expressing this (rather than having to verbosely implement it every time) would be a huge asset. Essentially it comes back to having a type system vs having to write your own manual type checks; same as using @NotNull vs checking for null arguments with an if. – Description

@KonradRudolph supercat referred to "a particular block of code"; given the block must be defined, declarative syntax would not significantly reduce bloat. If you're thinking that it would be declarative for the entire function, that would encourage bad programming since people would just stick in the declaration instead of actually looking at the checked exceptions potentially caught, and making sure there isn't some other better way to handle them. – Terryterrye

Answer 4

On any large enough system, with many layers, checked exception are useless as, anyway, you need an architectural level strategy to handle how the exception will be handled (use a fault barrier)

With checked exceptions your error handling stategy is micro-managed and its unbearable on any large system.

Most of the time you don't know if an error is "recoverable" because you don't know in what layer the caller of your API is located.

Let's say that I create a StringToInt API that converts the string representation of an integer to an Int. Must I throw a checked exception if the API is called with the "foo" string ? Is it recoverable ? I don't know because in his layer the caller of my StringToInt API may already have validated the input, and if this exception is thrown it's either a bug or a data corruption and it isn't recoverable for this layer.

In this case the caller of the API does not want to catch the exception. He only wants to let the exception "bubble up". If I chose a checked exception, this caller will have plenty of useless catch block only to artificially rethrow the exception.

What is recoverable depends most of the time on the caller of the API, not on the writter of the API. An API should not use checked exceptions as only unchecked exceptions allows to choose to either catch or ignore an exception.

Rommel

This is very close to userstories.blogspot.com/2008/12/… – Canopy

@Canopy Internet never fails to surprise me, actually it is my blog :) – Rommel

Answer 5

You're correct.

Unchecked exceptions are used to let the system fail fast which is a good thing. You should clearly state what is your method expecting in order to work properly. This way you can validate the input only once.

For instance:

/**
 * @params operation - The operation to execute.
 * @throws IllegalArgumentException if the operation is "exit"
 */
 public final void execute( String operation ) {
     if( "exit".equals(operation)){
          throw new IllegalArgumentException("I told you not to...");
     }
     this.operation = operation; 
     .....  
 }
 private void secretCode(){
      // we perform the operation.
      // at this point the opreation was validated already.
      // so we don't worry that operation is "exit"
      .....  
 }

Just to put an example. The point is, if the system fails fast, then you'll know where and why it did fail. You'll get an stacktrace like:

 IllegalArgumentException: I told you not to use "exit" 
 at some.package.AClass.execute(Aclass.java:5)
 at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
 ar ......

And you'll know what happened. The OtherClass in the "delegateTheWork" method ( at line 4569 ) called your class with the "exit" value, even when it shouldn't etc.

Otherwise you would have to sprinkle validations all over your code and that's error prone. Plus, sometimes it is hard to track what went wrong and you may expect hours of frustrating debugging

Same thing happens with NullPointerExceptions. If you have a 700 lines class with some 15 methods, that uses 30 attributes and none of them can be null, instead of validating in each of those methods for nullability you could make all those attributes read-only and validate them in the constructor or factory method.

 public static MyClass createInstane( Object data1, Object data2 /* etc */ ){ 
      if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }

  }


  // the rest of the methods don't validate data1 anymore.
  public void method1(){ // don't worry, nothing is null 
      ....
  }
  public void method2(){ // don't worry, nothing is null 
      ....
  }
  public void method3(){ // don't worry, nothing is null 
      ....
  }

Checked exceptions Are useful when the programmer ( you or your co-workers ) did everything right, validated the input, ran tests, and all the code is perfect, but the code connects to a third party webservice that may be down ( or a file you were using was deleted by another external process etc ) . The webservice may even be validate before the connection is attempted, but during the data transfer something went wrong.

In that scenario there is nothing that you or your co-workers can do to help it. But still you have to do something and not let the application just die and disappear in the eyes of the user. You use a checked exception for that and handle the exception, what can you do when that happens?, most of the time , just to attempt to log the error, probably save your work ( the app work ) and present a message to the user. ( The site blabla is down, please retry later etc. )

If the checked exception are overused ( by adding the "throw Exception" in the all the methods signatures ) , then your code will become very fragile, because everyone will ignore that exception ( because is too general ) and the quality of code will be seriously compromised.

If you overuse unchecked exception something similar will happen. The users of that code don't know if something may go wrong an a lot of try{...}catch( Throwable t ) will appear.

Yean

Well said! +1. It always surprises me this distinction caller(unchecked)/callee(checked) is not more obvious... – Boehmite

Answer 6

Here is my 'final rule of thumb'.
I use:

• unchecked exception within the code of my method for a failure due to the caller (that involves an explicit and complete documentation)
• checked exception for a failure due to the callee that I need to make explicit to anyone wanting to use my code

Compare to the previous answer, this is a clear rationale (upon which one can agree or disagree) for the use of one or the other (or both) kind of exceptions.

---

For both of those exceptions, I will create my own unchecked and checked Exception for my application (a good practice, as mentionned here), except for very common unchecked exception (like NullPointerException)

So for instance, the goal of this particular function below is to make (or get if already exist) an object,
meaning:

• the container of the object to make/get MUST exist (responsibility of the CALLER
  => unchecked exception, AND clear javadoc comment for this called function)
• the other parameters can not be null
  (choice of the coder to put that on the CALLER: the coder will not check for null parameter but the coder DOES DOCUMENT IT)
• the result CAN NOT BE NULL
  (responsibility and choice of the code of the callee, choice which will be of great interest for the caller
  => checked exception because every callers MUST take a decision if the object can not be created/found, and that decision must be enforced at the compilation time: they can not use this function without having to deal with this possibility, meaning with this checked exception).

Example:

---

/**
 * Build a folder. <br />
 * Folder located under a Parent Folder (either RootFolder or an existing Folder)
 * @param aFolderName name of folder
 * @param aPVob project vob containing folder (MUST NOT BE NULL)
 * @param aParent parent folder containing folder 
 *        (MUST NOT BE NULL, MUST BE IN THE SAME PVOB than aPvob)
 * @param aComment comment for folder (MUST NOT BE NULL)
 * @return a new folder or an existing one
 * @throws CCException if any problems occurs during folder creation
 * @throws AssertionFailedException if aParent is not in the same PVob
 * @throws NullPointerException if aPVob or aParent or aComment is null
 */
static public Folder makeOrGetFolder(final String aFoldername, final Folder aParent,
    final IPVob aPVob, final Comment aComment) throws CCException {
    Folder aFolderRes = null;
    if (aPVob.equals(aParent.getPVob() == false) { 
       // UNCHECKED EXCEPTION because the caller failed to live up
       // to the documented entry criteria for this function
       Assert.isLegal(false, "parent Folder must be in the same PVob than " + aPVob); }

    final String ctcmd = "mkfolder " + aComment.getCommentOption() + 
        " -in " + getPNameFromRepoObject(aParent) + " " + aPVob.getFullName(aFolderName);

    final Status st = getCleartool().executeCmd(ctcmd);

    if (st.status || StringUtils.strictContains(st.message,"already exists.")) {
        aFolderRes = Folder.getFolder(aFolderName, aPVob);
    }
    else {
        // CHECKED EXCEPTION because the callee failed to respect his contract
        throw new CCException.Error("Unable to make/get folder '" + aFolderName + "'");
    }
    return aFolderRes;
}

Boehmite

Answer 7

It's not just a matter of the ability to recover from the exception. What matter most, in my opinion, is whether the caller is interested in catching the exception or not.

If you write a library to be used elsewhere, or a lower-level layer in your application, ask yourself if the caller is interested in catching (knowing about) your exception. If he is not, then use an unchecked exception, so you don't burden him unnecessarily.

This is the philosophy used by many frameworks. Spring and hibernate, in particularly, come to mind - they convert known checked exception to unchecked exception precisely because checked exceptions are overused in Java. One example that I can think of is the JSONException from json.org, which is a checked exception and is mostly annoying - it should be unchecked, but the developer simply haven't thought it through.

By the way, most of the time the caller's interest in the exception is directly correlated to the ability to recover from the exception, but that is not always the case.

Furtherance

Answer 8

Here is a very simple solution to your Checked/Unchecked dilemma.

Rule 1: Think of a Unchecked Exception as a testable condition before code executes. for example…

x.doSomething(); // the code throws a NullPointerException

where x is null... …the code should possibly have the following…

if (x==null)
{
    //do something below to make sure when x.doSomething() is executed, it won’t throw a NullPointerException.
    x = new X();
}
x.doSomething();

Rule 2: Think of a Checked Exception as an un-testable condition that may occur while the code executes.

Socket s = new Socket(“google.com”, 80);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();

…in the example above, the URL (google.com) may be unavailable to due the DNS server being down. Even at the instant the DNS server was working and resolved the ‘google.com’ name to an IP address, if the connection is made to google.com, at anytime afterword, the network could go down. You simply can not test the network all the time before reading and writing to streams.

There are times where the code simply must execute before we can know if there is a problem. By forcing developers to write their code in such a way to force them to handle these situations via Checked Exception, I have to tip my hat to the creator of Java that invented this concept.

In general, almost all the APIs in Java follow the 2 rules above. If you try to write to a file, the disk could fill up before completing the write. It is possible that other processes had caused the disk to become full. There is simply no way to test for this situation. For those who interact with hardware where at any time, using the hardware can fail, Checked Exceptions seem to be an elegant solution to this problem.

There is a gray area to this. In the event that many tests are needed (a mind blowing if statement with lots of && and ||), the exception thrown will be a CheckedException simply because it’s too much of a pain to get right — you simply can’t say this problem is a programming error. If there are much less than 10 tests (e.g. ‘if (x == null)’), then the programmer error should be a UncheckedException.

Things get interesting when dealing with language interpreters. According to the rules above, should a Syntax Error be considered a Checked or Unchecked Exception? I would argue that if the syntax of the language can be tested before it gets executed, it should be an UncheckedException. If the language can not be tested — similar to how assembly code runs on a personal computer, then the Syntax Error should be a Checked Exception.

The 2 rules above will probably remove 90% of your concern over which to choose from. To summarize the rules, follow this pattern… 1) if the code to be execute can be tested before it’s executed for it to run correctly and if an Exception occurs — a.k.a. a programmer error, the Exception should be an UncheckedException (a subclass of RuntimeException). 2) if the code to be executed can not be tested before it’s executed for it to run correctly, the Exception should be a Checked Exception (a subclass of Exception).

Morehead

Answer 9

You can call it a checked or unchecked exception; however, both types of exception can be caught by the programmer, so the best answer is: write all of your exceptions as unchecked and document them. That way the developer who uses your API can choose whether he or she wants to catch that exception and do something. Checked exceptions are a complete waste of everyone's time and it makes your code a shocking nightmare to look at. Proper unit testing will then bring up any exceptions that you may have to catch and do something with.

Gaskill

+1 For mention that unit tests might be a better way to solve the problem checked exceptions are intended to solve. – Rhetorical

+1 for unit testing. Using Checked/Uncheked exceptions have little impact on code quality. So the argument that if one uses checked exceptions it would result in better code quality is complete bogus argument! – Italicize

Answer 10

Checked Exception: If client can recover from an exception and would like to continue, use checked exception.

Unchecked Exception: If a client can't do any thing after the exception, then raise unchecked exception.

Example: If you are expected to do arithmetic operation in a method A() and based on the output from A(), you have to another operation. If the output is null from method A() which you are not expecting during the run time, then you are expected to throw Null pointer Exception which is Run time exception.

Refer here

Muntin

Answer 11

Here is I want to share my opinion I have after many years of development experience:

1. Checked exception. This is a part of business use case or call flow, this is a part of application logic we expect or not expect. For example connection rejected, condition is not satisfied etc. We need to handle it and show corresponding message to user with instructions what happened and what to do next (try again later etc). I usually call it post-processing exception or "user" exception.

2. Unchecked exception. This is a part of programming exception, some mistake in software code programming (bug, defect) and reflects a way how programmers must use API as per documentation. If an external lib/framework doc says it expects to get data in some range and non null, because NPE or IllegalArgumentException will be thrown, programmer should expect it and use API correctly as per documentation. Otherwise the exception will be thrown. I usually call it pre-processing exception or "validation" exception.

By target audience. Now let's talk about target audience or group of people the exceptions have been designed (as per my opinion):

1. Checked exception. Target audience is users/clients.
2. Unchecked exception. Target audience is developers. By other words unchecked exception are designed for developers only.

By application development lifecycle phase.

1. Checked exception is designed to exist during whole production lifecycle as normal and expected mechanism an application handles exceptional cases.
2. Unchecked exception is designed to exist only during application development/testing lifecycle, all of them should be fixed during that time and should not be thrown when an application is running on production already.

The reason why frameworks usually use unchecked exceptions (Spring for example) is that framework cannot determine the business logic of your application, this is up to developers to catch then and design own logic.

Jink

Answer 12

We have to distinguish these two types of exception based on whether it is programmer error or not.

• If an error is a programmer error, it must be an Unchecked Exception. For example: SQLException/IOException/NullPointerException. These exceptions are programming errors. They should be handled by programmer. While in JDBC API, SQLException is Checked Exception, In Spring JDBCTemplate it is an Unchecked Exception.Programmer doesn't worry about SqlException, when use Spring.
• If an error is not a programmer error and the reason is coming from external, it must be a Checked Exception. For example: if the file is deleted or file permission is changed by someone else, It should be recovered.

FileNotFoundException is good example to understand subtle differences. FileNotFoundException is thrown in case file is not found. There are two reason for this exception. If the file path is defined by developer or taking from end user via GUI it should be an Unchecked Exception. If the file is deleted by someone else, it should be a Checked Exception.

Checked Exception can be handled in two ways. These are using try-catch or propagate the exception. In case of propagation of exception, all methods in call stack will be tightly coupled because of exception handling. That's why, we have to use Checked Exception carefully.

In case you develop an layered enterprise system, you have to choose mostly unchecked exception to throw, but don't forget to use checked exception for the case you cannot do anything.

Americaamerican

Answer 13

I agree with the preference for unchecked exceptions as a rule, especially when designing an API. The caller can always choose to catch a documented, unchecked exception. You're just not needlessly forcing the caller to.

I find checked exceptions useful at the lower-level, as implementation detail. It often seems like a better flow of control mechanism than having to manage a specified error "return code". It can sometimes help see the impact of an idea for a low level code change too... declare a checked exception downstream and see who would need to adjust. This last point doesn't apply if there are a lot of generic: catch(Exception e) or throws Exception which is usually not too well-thought out anyway.

Magnetron

Answer 14

I think we can think about exeptions from several questions:

why does exeption happen? What can we do when it happens

by mistake, a bug. such as a method of null object is called.

String name = null;
... // some logics
System.out.print(name.length()); // name is still null here

This kind of exception should be fixed during test. Otherwise, it breaks the production, and you got a very high bug which needs to be fixed immediately. This kind of exceptions do not need be checked.

by input from external, you cannot control or trust the output of external service.

String name = ExternalService.getName(); // return null
System.out.print(name.length());    // name is null here

Here, you may need to check whether the name is null if you want to continue when it is null, otherwise, you can let it alone and it will stop here and give the caller the runtime exception. This kind of exceptions do not need be checked.

by runtime exception from external, you cannot control or trust the external service.

Here, you may need to catch all exceptions from ExternalService if you want to continue when it happens, otherwise, you can let it alone and it will stop here and give the caller the runtime exception.

by checked exception from external, you cannot control or trust the external service.

Here, you may need to catch all exceptions from ExternalService if you want to continue when it happens, otherwise, you can let it alone and it will stop here and give the caller the runtime exception.

In this case, do we need to know what kind of exception happened in ExternalService? It depends:

1. if you can handle some kinds of exceptions, you need to catch them and process. For others, bubble them.

2. if you need log or response to user the specific execption, you can catch them. For others, bubble them.

Colangelo

Answer 15

Checked exceptions are useful for recoverable cases where you want to provide information to the caller (i.e. insufficient permissions, file not found, etc).

Unchecked exceptions are used rarely, if at all, for informing the user or programmer of serious errors or unexpected conditions during run-time. Don't throw them if you're writing code or libraries that will be used by others, as they may not be expecting your software to throw unchecked exceptions since the compiler doesn't force them to be caught or declared.

Spec

I disagree with your statement "Unchecked exceptions are used rarely, if at all" in fact it should be opposite! Use unchecked exceprions by default when you design your application exceptions hierarchy. Let developers to decide when they want to handle the exception (e.g. they are not forced to put catch blocks or put throws clause if they don't know how to handle it). – Italicize

Answer 16

Whnever an exception is less likely expected, and we can proceed even after catching that, and we can not do anything to avoid that exception then we can use checked exception.

Whenever we want to do something meaningful when a particular exceptions happens and when that exception is expected but not certain, then we can use checked exception.

Whenever exception navigating in different layers, we don't need to catch it in every layer, in that case, we can use runtime exception or wrap exception as unchecked exception.

Runtime exception is used when exception most likely to be happened, there is no way of going further and nothing can be recoverable. So in this case we can take precautions with respect to that exception. EX: NUllPointerException, ArrayOutofBoundsException. These are more likely to happen. In this scenario, we can take precautions while coding to avoid such exception. Otherwise we will have to write try catch blocks every where.

More general exceptions can be made Unchecked, less general are checked.

Virg

Answer 17

I think when declaring Application Exception it should be Unchecked Exception i.e., subclass of RuntimeException. The reason is it will not clutter application code with try-catch and throws declaration on method. If your application is using Java Api which throws checked exceptions that anyways need to be handle. For other cases, the application can throw unchecked exception. If the application caller still needs to handle unchecked exception, it can be done.

Cruise

Answer 18

The rule I use is: never use unchecked exceptions! (or when you don't see any way around it)

From the point of view of the developer using your library or the end-user using your library/application it really sucks to be confronted with an application that crashes due to an uncought exception. And counting on a catch-all is no good either.

This way the end user can still be presented with an error message, instead of the application completely disappearing.

Collectivism

You don't explain what you think is wrong with a catch-all for most unchecked exceptions. – Dowdell

Completely disagree with your un-argumented answer: "never use unchecked exceptions" – Italicize