I was this doubt , and when I was informed of it, another one came up to me, which I would like to clarify.
Exception and RuntimeException ? Exception or RuntimeException ? If possible a didactic example of using
ExceptionandRuntimeException.
RuntimeException should be used when the can be prevented. Use it, indirectly, when you want to signal to your code developer that he can try to resolve the problem when this exception is thrown. Because of this it is considered an unchecked exception.
They are often used in programming errors that can only be checked at runtime. That's why you do not have to capture. Programming error should let the application crash. They only occur because they are not prevented before they happen, so they are called programming errors. A check before the error occurs will resolve the problem. Examples of errors of this type are ArrayIndexOutOfBoundsException and NullPointerException .
Nothing prevents you from creating your own derivatives of this class. You just should not do this because you do not want to have the job of capturing later. The philosophy of Java is that whenever it is possible to do something with the problem, an exception must be captured, so this type of exception should be avoided as much as possible. This is not to say that any exception should be caught. Even the exceptions checked often it is best to delegate to another method. And the unchecked should only be captured if in that context you can do something to recover from the error, even if it is to present a personalized message.
For errors errors, we recommend using% wrapper that is more generic and involves any exceptions, including wrapper% since all exceptions must be derived from < a href="http://docs.oracle.com/javase/8/docs/api/java/lang/Exception.html"> Exception . It is also used indirectly. It is considered a checked exception. That is, all exceptions that are not RuntimeException are checked. Examples are all derived and the actual Exception or RuntimeException . These exceptions occur in a situation that the programmer is not usually able to control, depends on the use of the application and perhaps only the user of it can do something.
When a checked exception is used, the code should either capture it or use IOException (examples and more information on that question) in the method for delegating your catch. Runtime exceptions do not have to do this, as the name itself indicates they should not be considered by the compiler. Of course it's up to the programmer to analyze the situation and decide if that case should use a checked exception or not, when it's optional. There are cases that even a runtime error should be required to have some treatment when its flow depends on that correct and something can be handled better.
It is important to point out that the use of these classes is indirect because the ideal is to throw exceptions derived from them and not themselves that are very generic. You should always post the more specific exceptions possible .
You asked for didactic examples. What I have is what I learned from experience.
In the case of checked exceptions I see that data manipulation libraries commonly throw I / O-related and data-parsing exceptions. The classic Java I / O library, for example, throws IOException , FileNotFoundException and EOFException , to name the most common. Net networking libraries and HTTP communication because they also perform I / O throw at least IOException . A JSON parser such as json.org that comes along with Android may throw a JSONException related to reading a data from a JSON string, and Google Gson may cast a JsonSyntaxException . >
Finally, these are situations in which the library itself is not ready to deal with the error and chooses to pass it on to a higher level of call stack or call stack . It does this by declaring that such exceptions, if they occur, will need to be handled by those who make use of that API. This is one of the advantages of working with exceptions: just as you can treat them at the point they occur, you can also delegate this treatment to a level that is better able to treat or "recover" from the error that occurred.
When declaring this in the form of a checked exception , you are signaling the "user" code that that error deserves attention and probably some kind of handling. And typically it's a "recoverable" error: Your application can prepare for a malformed JSON, a missing file, or an interruption in network communication.
It is different from a runtime exception in that the runtime typically represents an error in the operation of the code itself, an error that you catch while executing and needs fix the code and prevent it from happening, as @bigown said. You need to "armor" your code against it. A parameter that can not be passed as null otherwise it will throw a IllegalArgumentException or a NullPointerException , a state that theoretically should not happen under penalty of throwing a IllegalStateException (example: a method that should only be called by thread from Android UI and you involuntarily call from a secondary thread), to name the types I most use currently. When my code throws one of these exceptions, I'll admit that I do not expect them to happen, but sometimes they happen and I know it's a code defect.
I confess that I have already dealt with IOException inside a library of my call to web services instead of delegating to the user code. I "swallowed" the exception (at most logged in) and returned null in my answer. It was a terrible design decision. My user code did not know when a null came from a successful request or when it came from an I / O error, and are two different situations that require different treatment. It was not my library that needed to handle I / O exceptions, but the code that made use of it.
In a more recent code where I use the Apache HTTP Client, I declare the following:
private HttpResponse executarRequisicaoSincrona(DataTransferRequest requisicao)
throws UnsupportedEncodingException, IOException {
See how this method delegates to another level two checked exceptions , a specific I / O (which is an unsupported encoding) and a more generic I / O. The two are likely to occur during an HTTP request in different situations and I found it fine not to treat them at the same level as they are launched but rather to pass them forward because at that time my code does not yet know what to do with they. If I did, I could treat them within the executarRequisicaoSincrona method instead of declaring them, but that's not the case in my code.
I hope with these experiments you can have a more precise notion of when to use or throw exceptions of the two types, checked and unchecked .
Update: This link explains very well the difference between the two and when to use one or the other (in fact it explains the best practices about handling exceptions in Java). I strongly recommend it: link