Develop Reference

Preparing for an exam on handing Exceptions, Why do we need throws? [duplicate]

Joshua Bloch in "Effective Java" said that
Use checked exceptions for
recoverable conditions and runtime
exceptions for programming errors
(Item 58 in 2nd edition)
Let's see if I understand this correctly.
Here is my understanding of a checked exception:
try{
String userInput = //read in user input
Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
id = 0; //recover the situation by setting the id to 0
}
1. Is the above considered a checked exception?
2. Is RuntimeException an unchecked exception?
Here is my understanding of an unchecked exception:
try{
File file = new File("my/file/path");
FileInputStream fis = new FileInputStream(file);
}catch(FileNotFoundException e){
//3. What should I do here?
//Should I "throw new FileNotFoundException("File not found");"?
//Should I log?
//Or should I System.exit(0);?
}
4. Now, couldn't the above code also be a checked exception? I can try to recover the situation like this? Can I? (Note: my 3rd question is inside the catch above)
try{
String filePath = //read in from user input file path
File file = new File(filePath);
FileInputStream fis = new FileInputStream(file);
}catch(FileNotFoundException e){
//Kindly prompt the user an error message
//Somehow ask the user to re-enter the file path.
}
5. Why do people do this?
public void someMethod throws Exception{
}
Why do they let the exception bubble up? Isn't handling the error sooner better? Why bubble up?
6. Should I bubble up the exact exception or mask it using Exception?
Below are my readings
In Java, when should I create a checked exception, and when should it be a runtime exception?
When to choose checked and unchecked exceptions

Many people say that checked exceptions (i.e. these that you should explicitly catch or rethrow) should not be used at all. They were eliminated in C# for example, and most languages don't have them. So you can always throw a subclass of RuntimeException (unchecked exception)
However, I think checked exceptions are useful - they are used when you want to force the user of your API to think how to handle the exceptional situation (if it is recoverable). It's just that checked exceptions are overused in the Java platform, which makes people hate them.
Here's my extended view on the topic.
As for the particular questions:
Is the NumberFormatException consider a checked exception?
No. NumberFormatException is unchecked (= is subclass of RuntimeException). Why? I don't know. (but there should have been a method isValidInteger(..))
Is RuntimeException an unchecked exception?
Yes, exactly.
What should I do here?
It depends on where this code is and what you want to happen. If it is in the UI layer - catch it and show a warning; if it's in the service layer - don't catch it at all - let it bubble. Just don't swallow the exception. If an exception occurs in most of the cases you should choose one of these:
log it and return
rethrow it (declare it to be thrown by the method)
construct a new exception by passing the current one in constructor
Now, couldn't the above code also be a checked exception? I can try to recover the situation like this? Can I?
It could've been. But nothing stops you from catching the unchecked exception as well
Why do people add class Exception in the throws clause?
Most often because people are lazy to consider what to catch and what to rethrow. Throwing Exception is a bad practice and should be avoided.
Alas, there is no single rule to let you determine when to catch, when to rethrow, when to use checked and when to use unchecked exceptions. I agree this causes much confusion and a lot of bad code. The general principle is stated by Bloch (you quoted a part of it). And the general principle is to rethrow an exception to the layer where you can handle it.

Whether something is a "checked exception" has nothing to do with whether you catch it or what you do in the catch block. It's a property of exception classes. Anything that is a subclass of Exception except for RuntimeException and its subclasses is a checked exception.
The Java compiler forces you to either catch checked exceptions or declare them in the method signature. It was supposed to improve program safety, but the majority opinion seems to be that it's not worth the design problems it creates.
Why do they let the exception bubble
up? Isnt handle error the sooner the
better? Why bubble up?
Because that's the entire point of exceptions. Without this possibility, you would not need exceptions. They enable you to handle errors at a level you choose, rather than forcing you to deal with them in low-level methods where they originally occur.

Is the above considered to be a checked exception?
No
The fact that you are handling an exception does not make it a Checked Exception if it is a RuntimeException.
Is RuntimeException an unchecked exception?
Yes
Checked Exceptions are subclasses of java.lang.Exception
Unchecked Exceptions are subclasses of java.lang.RuntimeException
Calls throwing checked exceptions need to be enclosed in a try{} block or handled in a level above in the caller of the method. In that case the current method must declare that it throws said exceptions so that the callers can make appropriate arrangements to handle the exception.
Hope this helps.
Q: should I bubble up the exact
exception or mask it using Exception?
A: Yes this is a very good question and important design consideration. The class Exception is a very general exception class and can be used to wrap internal low level exceptions. You would better create a custom exception and wrap inside it. But, and a big one - Never ever obscure in underlying original root cause. For ex, Don't ever do following -
try {
attemptLogin(userCredentials);
} catch (SQLException sqle) {
throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}
Instead do following:
try {
attemptLogin(userCredentials);
} catch (SQLException sqle) {
throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}
Eating away original root cause buries the actual cause beyond recovery is a nightmare for production support teams where all they are given access to is application logs and error messages.
Although the latter is a better design but many people don't use it often because developers just fail to pass on the underlying message to caller. So make a firm note: Always pass on the actual exception back whether or not wrapped in any application specific exception.
On try-catching RuntimeExceptions
RuntimeExceptions as a general rule should not be try-catched. They generally signal a programming error and should be left alone. Instead the programmer should check the error condition before invoking some code which might result in a RuntimeException. For ex:
try {
setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
sendError("Sorry, your userObject was null. Please contact customer care.");
}
This is a bad programming practice. Instead a null-check should have been done like -
if (userObject != null) {
setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
sendError("Sorry, your userObject was null. Please contact customer care.");
}
But there are times when such error checking is expensive such as number formatting, consider this -
try {
String userAge = (String)request.getParameter("age");
userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}
Here pre-invocation error checking is not worth the effort because it essentially means to duplicate all the string-to-integer conversion code inside parseInt() method - and is error prone if implemented by a developer. So it is better to just do away with try-catch.
So NullPointerException and NumberFormatException are both RuntimeExceptions, catching a NullPointerException should replaced with a graceful null-check while I recommend catching a NumberFormatException explicitly to avoid possible introduction of error prone code.

1 . If you are unsure about an exception, check the API:
java.lang.Object
extended by java.lang.Throwable
extended by java.lang.Exception
extended by java.lang.RuntimeException //<-NumberFormatException is a RuntimeException
extended by java.lang.IllegalArgumentException
extended by java.lang.NumberFormatException
2 . Yes, and every exception that extends it.
3 . There is no need to catch and throw the same exception. You can show a new File Dialog in this case.
4 . FileNotFoundException is already a checked exception.
5 . If it is expected that the method calling someMethod to catch the exception, the latter can be thrown. It just "passes the ball". An example of it usage would be if you want to throw it in your own private methods, and handle the exception in your public method instead.
A good reading is the Oracle doc itself: http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html
Why did the designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Any Exception that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them. These exceptions are as much a part of that method's programming interface as its parameters and return value.
The next question might be: "If it's so good to document a method's API, including the exceptions it can throw, why not specify runtime exceptions too?" Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.
There's also an important bit of information in the Java Language Specification:
The checked exception classes named in the throws clause are part of the contract between the implementor and user of the method or constructor.
The bottom line IMHO is that you can catch any RuntimeException, but you are not required to and, in fact the implementation is not required to maintain the same non-checked exceptions thrown, as those are not part of the contract.

1) No, a NumberFormatException is an unchecked Exception. Even though you caught it (you aren't required to) because it's unchecked. This is because it is a subclass of IllegalArgumentException which is a subclass of RuntimeException.
2) RuntimeException is the root of all unchecked Exceptions. Every subclass of RuntimeException is unchecked. All other Exceptions and Throwable are checked except for Errors ( Which comes under Throwable).
3/4) You could alert the user that they picked a non-existent file and ask for a new one. Or just quit informing the user that they entered something invalid.
5) Throwing and catching 'Exception' is bad practice. But more generally, you might throw other exceptions so the caller can decide how to deal with it. For example, if you wrote a library to handle reading some file input and your method was passed a non-existent file, you have no idea how to handle that. Does the caller want to ask again or quit? So you throw the Exception up the chain back to the caller.
In many cases, an unchecked Exception occurs because the programmer did not verify inputs (in the case of NumberFormatException in your first question). That's why its optional to catch them, because there are more elegant ways to avoid generating those exceptions.

Checked - Prone to happen. Checked in Compile time.
Eg.. FileOperations
UnChecked - Due to Bad data. Checked in Run time.
Eg..
String s = "abc";
Object o = s;
Integer i = (Integer) o;
Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
at Sample.main(Sample.java:9)
Here exception is due to bad data and in no way it can be determined during compile time.

Runtime Exceptions :
Runtime exceptions are referring to as unchecked exceptions. All other exceptions
are checked exceptions, and they don't derive from java.lang.RuntimeException.
Checked Exceptions :
A checked exception must be caught somewhere in your code. If you invoke a
method that throws a checked exception but you don't catch the checked exception
somewhere, your code will not compile. That's why they're called checked
exceptions : the compiler checks to make sure that they're handled or declared.
A number of the methods in the Java API throw checked exceptions, so you will often write exception handlers to cope with exceptions generated by methods you didn't write.

Checked exceptions are checked at compile time by the JVM and its related to resources(files/db/stream/socket etc). The motive of checked exception is that at compile time if the resources are not available the application should define an alternative behaviour to handle this in the catch/finally block.
Unchecked exceptions are purely programmatic errors, wrong calculation, null data or even failures in business logic can lead to runtime exceptions. Its absolutely fine to handle/catch unchecked exceptions in code.
Explanation taken from http://coder2design.com/java-interview-questions/

My absolute favorite description of the difference between unchecked and checked exceptions is provided by the Java Tutorial trail article, "Unchecked Exceptions - the Controversy" (sorry to get all elementary on this post - but, hey, the basics are sometimes the best):
Here's the bottom line guideline: If a client can reasonably be
expected to recover from an exception, make it a checked exception. If
a client cannot do anything to recover from the exception, make it an
unchecked exception
The heart of "what type of exception to throw" is semantic (to some degree) and the above quote provides and excellent guideline (hence, I am still blown away by the notion that C# got rid of checked exceptions - particularly as Liskov argues for their usefulness).
The rest then becomes logical: to which exceptions does the compiler expect me to respond, explicitly? The ones from which you expect client to recover.

To answer the final question (the others seem thoroughly answered above), "Should I bubble up the exact exception or mask it using Exception?"
I am assuming you mean something like this:
public void myMethod() throws Exception {
// ... something that throws FileNotFoundException ...
}
No, always declare the most precise exception possible, or a list of such. The exceptions you declare your method as capable of throwing are a part of the contract between your method and the caller. Throwing "FileNotFoundException" means that it is possible the file name isn't valid and the file will not be found; the caller will need to handle that intelligently. Throwing Exception means "Hey, sh*t happens. Deal." Which is a very poor API.
In the comments on the first article there are some examples where "throws Exception" is a valid and reasonable declaration, but that's not the case for most "normal" code you will ever write.

I think that checked exceptions are a good reminder for the developer that uses an external library that things can go wrong with the code from that library in exceptional situations.

Why do they let the exception bubble up? Isn't handling the error sooner better? Why bubble up?
For example let say you have some client-server application and client had made a request for some resource that couldn't be find out or for something else error some might have occurred at the server side while processing the user request then it is the duty of the server to tell the client why he couldn't get the thing he requested for,so to achieve that at server side, code is written to throw the exception using throw keyword instead of swallowing or handling it.if server handles it/swallow it, then there will be no chance of intimating to the client that what error had occurred.
Note:To give a clear description of what the error type has occurred we can create our own Exception object and throw it to the client.

I just want to add some reasoning for not using checked exceptions at all. This is not a full answer, but I feel it does answer part of your question, and complements many other answers.
Whenever checked exceptions are involved, there's a throws CheckedException somewhere in a method signature (CheckedException could be any checked exception). A signature does NOT throw an Exception, throwing Exceptions is an aspect of implementation. Interfaces, method signatures, parent classes, all these things should NOT depend on their implementations. The usage of checked Exceptions here (actually the fact that you have to declare the throws in the method signature) is binding your higher-level interfaces with your implementations of these interfaces.
Let me show you an example.
Let's have a nice and clean interface like this
public interface IFoo {
public void foo();
}
Now we can write many implementations of method foo(), like these
public class Foo implements IFoo {
#Override
public void foo() {
System.out.println("I don't throw and exception");
}
}
Class Foo is perfectly fine. Now let's make a first attempt at class Bar
public class Bar implements IFoo {
#Override
public void foo() {
//I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
throw new InterruptedException();
}
}
This class Bar won't compile. As InterruptedException is a checked exception, you must either capture it (with a try-catch inside method foo()) or declare that you're throwing it (adding throws InterruptedException to the method signature). As I don't want to capture this exception here (I want it to propagate upwards so I can properly deal with it somewhere else), let's alter the signature.
public class Bar implements IFoo {
#Override
public void foo() throws InterruptedException {
throw new InterruptedException();
}
}
This class Bar won't compile either! Bar's method foo() does NOT override IFoo's method foo() since their signatures are different. I could remove the #Override annotation, but I want to program against interface IFoo like IFoo foo; and later on decide on which implementation I want to use, like foo = new Bar();. If Bar's method foo() doesn't override IFoo's method foo, when I do foo.foo(); it won't call Bar's implementation of foo().
To make Bar's public void foo() throws InterruptedException override IFoo's public void foo() I MUST add throws InterruptedException to IFoo's method signature. This, however, will cause problems with my Foo class, since it's foo() method's signature differs from IFoo's method signature. Furthermore, if I added throws InterruptedException to Foo's method foo() I would get another error stating that Foo's method foo() declares that it throws an InterruptedException yet it never throws an InterruptedException.
As you can see (if I did a decent job at explaining this stuff), the fact that I'm throwing a checked exception like InterruptedException is forcing me to tie my interface IFoo to one of it's implementations, which in turn causes havoc on IFoo's other implementations!
This is one big reason why checked exceptions are BAD. In caps.
One solution is to capture the checked exception, wrap it in an unchecked exception and throw the unchecked exception.

Java distinguishes between two categories of exceptions (checked & unchecked).
Java enforces a catch or declared requirement for checked exceptions.
An exception's type determines whether an exception is checked or unchecked.
All exception types that are direct or indirect subclasses of class RuntimeException
are unchecked exception.
All classes that inherit from class Exception but not RuntimeException are considered to be checked exceptions.
Classes that inherit from class Error are considered to be unchecked.
Compiler checks each method call and deceleration to determine whether the
method throws checked exception.
If so the compiler ensures the exception is caught or is declared in a throws clause.
To satisfy the declare part of the catch-or-declare requirement, the method that generates
the exception must provide a throws clause containing the checked-exception.
Exception classes are defined to be checked when they are considered important enough to catch or declare.

Here is a simple rule that can help you decide. It is related to how interfaces are used in Java.
Take your class and imagine designing an interface for it such that the interface describes the functionality of the class but none of the underlying implementation (as an interface should). Pretend perhaps that you might implement the class in another way.
Look at the methods of the interface and consider the exceptions they might throw:
If an exception can be thrown by a method, regardless of the underlying implementation (in other words, it describes the functionality only) then it should probably be a checked exception in the interface.
If an exception is caused by the underlying implementation, it should not be in the interface. Therefore, it must either be an unchecked exception in your class (since unchecked exceptions need not appear in the interface signature), or you must wrap it and rethrow as a checked exception that is part of the interface method.
To decide if you should wrap and rethrow, you should again consider whether it makes sense for a user of the interface to have to handle the exception condition immediately, or the exception is so general that there is nothing you can do about it and it should propagate up the stack. Does the wrapped exception make sense when expressed as functionality of the new interface you are defining or is it just a carrier for a bag of possible error conditions that could also happen to other methods? If the former, it might still be a checked exception, otherwise it should be unchecked.
You should not usually plan to "bubble-up" exceptions (catch and rethrow). Either an exception should be handled by the caller (in which case it is checked) or it should go all the way up to a high level handler (in which case it is easiest if it is unchecked).

Just to point out that if you throw a checked exception in a code and the catch is few levels above, you need to declare the exception in the signature of each method between you and the catch. So, encapsulation is broken because all functions in the path of throw must know about details of that exception.

In short, exceptions which your module or modules above are supposed to handle during runtime are called checked exceptions; others are unchecked exceptions which are either RuntimeException or Error.
In this video, it explains checked and unchecked exceptions in Java:
https://www.youtube.com/watch?v=ue2pOqLaArw

All of those are checked exceptions. Unchecked exceptions are subclasses of RuntimeException. The decision is not how to handle them, it's should your code throw them. If you don't want the compiler telling you that you haven't handled an exception then you use an unchecked (subclass of RuntimeException) exception. Those should be saved for situations that you can't recover from, like out of memory errors and the like.

Checked Exceptions :
The exceptions which are checked by the compiler for smooth execution of the program at runtime are called Checked Exception.
These occur at compile time.
If these are not handled properly, they will give compile time error (Not Exception).
All subclasses of Exception class except RuntimeException are Checked Exception.
Hypothetical Example - Suppose you are leaving your house for the exam, but if you check whether you took your Hall Ticket at home(compile time) then there won't be any problem at Exam Hall(runtime).
Unchecked Exception :
The exceptions which are not checked by the compiler are called Unchecked Exceptions.
These occur at runtime.
If these exceptions are not handled properly, they don’t give compile time error. But the program will be terminated prematurely at runtime.
All subclasses of RunTimeException and Error are unchecked exceptions.
Hypothetical Example - Suppose you are in your exam hall but somehow your school had a fire accident (means at runtime) where you can't do anything at that time but precautions can be made before (compile time).

If anybody cares for yet another proof to dislike checked exceptions, see the first few paragraphs of the popular JSON library:
"Although this is a checked exception, it is rarely recoverable. Most callers should simply wrap this exception in an unchecked exception and rethrow: "
So why in the world would anyone make developers keep checking the exception, if we should "simply wrap it" instead? lol
http://developer.android.com/reference/org/json/JSONException.html

All exceptions must be checked exceptions.
Unchecked exceptions are unrestricted gotos. And unrestricted gotos are considered a bad thing.
Unchecked exceptions break encapsulation. To process them correctly, all the functions in the call tree between the thrower and the catcher must be known to avoid bugs.
Exceptions are errors in the function that throws them but not errors in the function that processes them. The purpose of exceptions is to give the program a second chance by deferring the decision of whether it's an error or not to another context. It's only in the other context can the correct decision be made.

Java API and checked/unchecked exceptions confusion

The question about checked and unchecked exceptions was raised here and on other websites million times, but I'm still confused with so different answers.
In many answers and articles we can read general statements like:
Unchecked runtime exceptions represent conditions that, generally
speaking, reflect errors in your program's logic and cannot be
reasonably recovered from at run time.
and for checked exceptions
represent invalid conditions in areas outside the immediate control of
the program (invalid user input, database problems, network outages,
absent files)
both quotes are from http://www.javapractices.com/topic/TopicAction.do?Id=129 and are cited many times.
We can read similar statements on oracle website:
Runtime exceptions represent problems that are the result of a
programming problem, and as such, the API client code cannot
reasonably be expected to recover from them or to handle them in any
way
http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
Lets take simple example with reading Number with Scanner:
Scanner sc = new Scanner(System.in);
int userInput = sc.nextInt();
System.out.println(userInput);
nextInt() throws InputMismatchException when I type i.e. "asdf" instead of int. InputMismatchException is RuntimeException but according to statements above this is the first example of checked exceptions "invalid user input".
When I look at checked exceptions I am even more confused. For example NPE vs FileNotFoundException - both can be prevented by simple if-else, so why first one is unchecked and second is checked?
Oracle website has bottom line guideline:
If a client can reasonably be expected to recover from an exception,
make it a checked exception. If a client cannot do anything to recover
from the exception, make it an unchecked exception.
So according to that I can recover from FileNotFoundException or IOException but I can't from NPE or ArrayIndexOutOfBoundsException? This makes no sense.
Maybe someone has better explanation to this with some better example?

To be very simple and factual :
an unchecked exception (Runtime class and children) conveys an unexpected exception.
In general, the caller should not know how to handle it and doesn't wait for it in any of his scenarios.
a checked exception conveys a exception that you may consider as a "normal" exception and the caller know how to handle it. It is probably not the nominal case for him but the caller knows that it could happen and should prepare himself to handle it.
In your example :
nextInt() throws InputMismatchException when I type i.e. "asdf"
instead of int. InputMismatchException is RuntimeException but
according to statements above this is the first example of checked
exceptions "invalid user input".
When a method calls nextInt() the caller waits for a int value. It is the excepted scenario. If it was not the case the user would do rather : next() to retrieve a String object and try then to convert it by something that suits.
When you invoke nextInt(), the caller waits for an int as he has requested it. Force him to handle InputMismatchException as a checked Exceptionwould be counter-intuitive.
So according to that I can recover from FileNotFoundException or
IOException but I can't from NPE or ArrayIndexOutOfBoundsException?
This makes no sense.
I think JDK Exceptions as FileNotFoundException or IOException are special cases. They are probably checked not necessarily because the client of these classes waits for that the file is not found or the stream generates some exceptions during reading or writing but rather because a stream may be in a not suitable state and consequently raises exception for many external reasons (file locked, lack of right, file moved to another place or to a not reachable network and so for...).
A file that generates an exception is probably considered as something that is important to handle.
So, the JDK specification prefers that the caller handles it explicitly.
Besides, before the arrival of the try-with-resources statement, the caller should explicitly close streams in case of exceptions.
NPE and ArrayIndexOutOfBoundsException are generally programming errors. The application cannot do a processing to recover specifically errors which it doesn't know the existence. So why make them checked ?

every single exception may or may not be recoverable in your app. it always depends on the context. if some object is null and you get NPE (unchecked) it may result in an empty expression language expression (so in this particular context, this situation is perfectly recoverable). on the other hand, you may get IOException (checked) which is irrecoverable because your web application can't connect to database and therefore is useless in context of this particular web application.
Maybe someone has better explanation to this
there is a better explanation: making checked and unchecked exception was simply a wrong design decision of language authors. and it decision won't be changed as long as java remains backward compatible.
so just:
ignore this artificial division (as other modern languages decided to do)
when design your api always use unchecked
when working with checked exception, wrap them in unchecked deep down the call stack (your life will be easier)
when calling a method always think/check what exceptions it may throw (checked or unchecked) and decide for every one of them if you should handle it or rethrow/pass through

Java Programming , returning in case of an error

I want to know the the best programming practice in the following use-case for a method say myMethod--
1) myMethod has some numerical purpose - say modify the contents of an array which is a private variable of the class
2) Before it does so, i need to run some critical checks on the numbers,say check1, check2, check3, any of which if fail, there is no point in going ahead. for eg. check might be to check for any negative numbers in array.
So this brings the question, what should myMethod return, how should the calling function be told that checkX has failed.

You should throw Exceptions if any of these checks fail.
Now the question is what kind of Exception to throw. Checked or unchecked? Checked Exceptions must be caught by the calling code where as unchecked do not (but that means they might bubble up to the top of the call stack all the way up to your main method). There is vigorous debate which is better. Either way, make sure to document which Exceptions are thrown.
In general, you should use checked exceptions for recoverable conditions and unchecked exceptions for programming errors (Effective Java 2nd ed Item 58)
there are many built in unchecked Exceptions in Java that you should use in preference to writing your own including but not limited to.
IllegalArgumentException
IllegalStateException
IndexOutOfBoundsException
NullPointerException
Take a look at the core Java methods to see what they throw.
Exceptions are better than return values because:
You must rely on users to check the return value and do something about it.
You are stuck with a method signature that returns a boolean or return code which might not be what you want.
The Exception can have a very descriptive error message explaining why it was thrown.

You can create a custom checked exception as follows:
class ArrayModificationException extends Exception{
public ArrayModificationException(String message){
super(message);
}
}
now in your "myMethod" add following:
void myMethod() throws ArrayModificationException{
//code to check conditions before modifications
//code to modify an array
if(check fails){
throw new ArrayModificationException("cusom message");
}
}
where custom message would be specific message conveying the exact reason of failure.
Of course the called will decide if to handle it or re-throw it. If this is one of conditions where your code should not try to recover itself you can design this as run-time exception and just throw it without throws clause for your method

There is no "best practice" here. It depends entirely on what your code does, where it's being executed, what the caller of the method expects, what should happen in erroneous cases, etc. Context is key here.

One possibility would be to throw an exception from the failing check, which would then be caught in the calling method.
Another option would to have myMethod return a boolean of true if all of the checks pass and the modification/calculation is done, and false otherwise.
As new_web_programmer said, though, it completely depends on what you are trying to do.

In general after a failed validation I do
throw new IllegalArgumentException("... Clue to the error and its repair...");
IllegalStateException is an alternative here.
This enables the function to continue as desired on success.
If the exception must be catched, not propagated, use your own Exception.

If the check failure is expected to be an exceptional circumstance, then throw an exception. Good examples are if a parameter is null but null is disallowed, or if a array index is out of range.
If your functio is supposed to return a reasonable value based on the inputs, such as returning the Point clisest to 0,0 then you could return a reasonable value based upo the check failures. For example, retur null if the array of Points is empty, or if the array itself is null.
In any case, be sure to clearly document (in the method's javadoc) what inputs result in the failure and what the expected behavior is, so that your callers are not surprised.

This brings up a very old debate whether to use exceptions or error codes.
You can read more about it here:
Exceptions or error codes

try{
check1
}catch(Exception e){
throw new CustomException("failed due to check1");
}
Some thing like this may be a better practice.

Custom RunTime Exceptions

So this is regarding an interview question I was recently asked. The interviewer started on this by asking me how we create our custom Exceptions. On answering that, he asked me how I'd create a RunTimeExceptions. I said we'd create them in the same way as we would create the checked Exceptions. Just our custom exception would extend from the RunTimeException class. Then he asked in what scenarios would you create your own RunTimeException. Now I couldn't think of a good answer to that. In none of my projects, we created custom RunTimeExceptions.
I also think that we should never create RunTimeExceptions. JVM can fail only in a finite number of ways and it handles them well. While writing an application we can't predict what runtime exceptions can occur and hence we shouldn't need to handle them. And if we can predict those conditions, they aren't RunTimeExceptions then. Since we neither need new runtime exceptions, nor need a handling of runtimeexceptions, why would we ever need to create a custom RunTimeException. Everything that we can pre-think of as a possible failure condition should be handled at compile time and it would be a checked exception. Right? Only the things that cannot be handled at compile time and the ones that depend on run time things go into the category of RunTimeExceptions.
Even if we write custom RunTimeExceptions and then a custom method that should throw that RunTimeException - how do we make sure that the method will throw that particular RunTimeException. How do we do that mapping. It doesn't seem possible to me.
Am I missing something/ many things here? Kindly advice.
Thanks,
Chan.

I think the interviewer was trying to see if you understand the purpose of runtime exceptions, which is to signal programmer's errors (as opposed to application exceptions, which signal problems with the execution environment).
You can and you should create subclasses of RuntimeException whenever your method needs to signal a condition that amounts to a programming error, and you need to provide additional information regarding the error the exception describes.
For example, consider a class that lets you store data in a sparse multidimensional array. One of the APIs such class would probably provide is a getter that takes an array of indexes. The number of indexes needs to equal the number of dimensions in the array, and each index must be within its bounds. Supplying an array parameter that has an incorrect number of elements, or has one or more element outside its bounds, is a programming error. You need to signal it with a runtime exception. If you want to signal this error, and provide a full account of what went wrong, your subclass IllegalArgumentException, a subclass of RuntimeException, to build your own exception.
Finally, there is one more situation when you want to subclass RuntimeException: when you should provide a "regular" exception, but you do not want your users to wrap each call of your API in a try/catch block. In situations like these, you can replace a single method
void performOperation() throws CustomApplicationException;
with a pair of methods
boolean canPerformOperation();
void performOperation();
The first method tells the caller that it is safe to call the second method in the current state; it never throws an exception.
The second method fail only in the state when the first method returns false, making a failure a programming error, thus justifying the use of RuntimeException to signal such failures.

Checked Exception vs Unchecked Exception is a long time debate among Java developers. I'm not be here to ignite the fire, but only want to share with you how I use it in our work.
For example, another service call my server for customer information. The input is customerID, and I will return a customer object
// Web Service interface
public CustomerInfo getCustomerInformation(int customerId, int securityToken) {
check(securityToken);
Customer customer = merchantService.getCustomer(customerId);
return customer.getInfo();
}
// MerchantService
public Customer getCustomer(int customerId) {
return customerService.getCustomer(customerId);
}
What will happen if the system can't find a particular customer? Of course it will throw an exception or return null. But returning null is bad, since it will make you check null everytime calling from a service. So I go with throwing exception:
// Customer service
public Customer getCustomer(id) {
Customer customer = getCustomerFromDB();
if (customer == null) throw CustomerNotExistedException();
return customer;
}
Now the question is whether CustomerNotExistedException is a Exception or a RuntimeException. If it's a checked exception, you will need to catch and process it at the function that calls getCustomer. That means you must catch it at MerchantService. However, all you want is to produce a 404 error at WebService level, so that catching it at MerchantService won't do anything more than throwing the exception again. It pollutes the code.
In the general case, I often use RuntimeException to let some exception "bubble up" to the level in which they can be processed.
For your reference, I would recommend the book Clean code from Robert C. Martin. It explains quite well how we should use exception to handle errors in Java.

You would create your own RuntimeException subclass if:
You don't want it to be a checked exception, because you don't expect callers to explicitly catch the exception. (Personally I believe that checked exceptions are rather overused in the standard library.)
You still want to provide more information than just a message (just the type itself is a helpful starting point in a log).
HibernateException is an example of this in the Hibernate ORM.

I think when you are creating Custom Exceptions , please don't subclass RuntimeException , it defeats the whole purpose of creating the custom exception.
Even if we write custom RunTimeExceptions and then a custom method that should throw that RunTimeException - how do we make sure that the method will throw that particular RunTimeException.
The point here is actually the caller of the method needn't surround that in a try-catch block as it is not a checked exception. Unless you have a good reason to throw a custom unchecked exception , say , just to provide additional custom information for logging etc. don't do that. Another bad implementation will be sometimes you would to just want to catch the checked exceptions in your code and throw custom unchecked exceptions to get rid of all the try-catch in the caller code.

What exception to throw?

I have a function which calculates the mean of a list passed as an argument. I would like to know which of Java exception should I throw when I try to compute the mean of a list of size 0.
public double mean (MyLinkedList<? extends Number> list)
{
if (list.isEmpty())
throw new ????????; //If I am not mistaken Java has some defined exception for this case
//code goes here
}
Thanks.

You can throw a new IllegalArgumentException().
Thrown to indicate that a method has been passed an illegal or inappropriate argument.
Just don't forget to pass a clear message as a first argument. This will really help you to understand what happend.
For example "Can't use mean on an empty List".

The question to ask yourself first is whether you should be throwing at all and then, if so, whether it should be a checked or unchecked exception.
Unfortunately, there's no industry best practice on deciding these things, as shown by this StackOverflow answer:
In Java, when should I create a checked exception, and when should it be a runtime exception?
Nevertheless, there are some key considerations:
Your design/vision for how this method is supposed to work (Is it reasonable/normal for the method to be called with 0-size list)?
Consistency with other methods in the class/package
Compliance with your applicable coding standard (if any)
My opinion:
Return Double.NAN or 0 If calling the method with a 0-size list is reasonable/expected/normal, I'd consider returning Double.NAN or 0 if 0 is appropriate for your problem domain.
Throw anIllegalArgumentException If my design says that checking for an empty List is strongly the responsibility of the caller and the documentation for the method is going to clearly state that it is the responsibility of the caller, then I'd use the standard unchecked IllegalArgumentException.
Throw a custom checked exception If the method is part of a statistics package or library where several statistics functions need to deal with an possible empty data set, I'd think this is an exception condition that is part of the problem domain. I'd create a custom (probably checked) exception (e.g. EmptyDataSetException) to be part of the class/package/library and use it across all applicable methods. Making it a checked exceptions helps remind the client to consider how to handle the condition.

You should create a new class that extends Exception and provides details specific to your error. For example you could create a class called EmptyListException that contains the details regarding your error. This could be a very simple exception class that takes no constructor arguments but maybe calls super("Cannot generate mean for an empty list"); to provide a custom message to the stack trace.
A lot of times this isn't done enough...one of my most hated code smells is when developers use a generic exception (even sometimes Exception itself) and pass a string message into the constructor. Doing this is valid but makes the jobs of those implementing your code much harder since they have to catch a generic exception when really only a few things could happen. Exceptions should have the same hierarchy as objects you use for data with each level providing more specific details. The more detailed the exception class, the more detailed and helpful the stack trace is.
I've found this site: Exceptional Strategies to be very useful when creating Exceptions for my applications.

IllegalArgumentException

How about NoSuchElementException. Although IllegalArgumentException might be better.

How about an ArithmeticException - the same as the runtime throws.

Are you currently throwing any other exceptions (or planning to?) Any of the previously mentioned exceptions are fine, or just create your own. The most important thing is propagating the message of what went wrong.
If there's a chance the 'catcher' of the exception might re-throw it, than you may want to investigate any other exceptions the 'catcher' might also throw.

I am not convinced you should be throwing an exception there at all; the average of "nothing" is "nothing" or 0 if you will. If the set is empty, you should simply return 0.
If you really MUST throw an exception, then IllegalStateException or IllegalArgumentException are your best choices.