-3

I am trying to understand try-catch block. Mostly, I got the point but there are two points, which I did not understand and do not know with which terms should I search them.

try{
    operation1;
    operation2;
    operation3;
    operation4;
}catch(Exception e){
//exception handling here.
}

Q1: For example, in an example like on the above. If the operation1 and operation2 are completed successfully but during the operation3, if it throws an exception, Will operation1 and operation2 be undone? or will they stay with the values after operations?

Q2. In case I do not know, which exceptions may my operations throw. What would be the best approach to this? As far as I know, throwing simply Exception is not a good practice.

drJava
  • 697
  • 2
  • 9
  • 24
  • WIth regards to Q1: The operations are not undone. That's what the catch block is there for. If there is something to be undone, you would handle that in the catch block. This might also lead into Q2 (not sure if I understand the question correctly)... If you need some information as to what error happened, you could create your own exception class that will help you recover from the exception in the catch block. – forrert Jun 03 '16 at 19:58
  • 1
    I suggest reading [Catching and Handling Exceptions](https://docs.oracle.com/javase/tutorial/essential/exceptions/handling.html). – mre Jun 03 '16 at 20:00
  • You wil be forced to catch or throw all checked exception, so you will know all checked exception you should be expecting. If you do not know which unchecked exception to expect, you probably dont know how to handle that unchecked exception as well. In that case, do not just swallow it mistakenly, i will rather let the system fail in that case ( if i can not recover or handle it proerply) – Jimmy Jun 03 '16 at 20:04
  • 1
    @mre Thank you for the link. I have already found it but especially with my second question, I would like to hear some experiences rather than technical information. – drJava Jun 03 '16 at 20:05
  • @Jimmy Do you mean letting the system down is better than throwing "Exception", which contains all exceptions? – drJava Jun 03 '16 at 20:06
  • 1
    if you throw all exception but do not catch it later, it will bring your system down any way. However, if you swallow exception unintenionally, you wont know if you ever had problem in your code. Which means you could lose the trace of that problem and would not notice at all. In that case, if you let the exception propagate, you will have full trace printed/logged and know something went wrong and fix it . – Jimmy Jun 03 '16 at 20:13
  • 1
    Basically if you cant handle or recover from exception , do not catch it . Everyone may not agree, but thats what I do. My recommendation for you is to look more into exception handling specially about propagation and unintentional exception swallowing. – Jimmy Jun 03 '16 at 20:16

2 Answers2

2

The best practice would be to not surround long lines of code with a single try-catch. By doing this you run into the exact ambiguity you mention: did any of my statements complete? Which threw the exception?

Instead, each statement should get its own try-catch block if they each can throw an exception. Unless the results of the try-catch are discarded in the catch, then you should avoid lumping all of the operations together.

As for which exceptions are thrown - you either have to know based off of what you're doing (Ex. when you access arrays, if you know you might go out of bounds you can catch the ArrayOutOfBoundsException). However, in most cases, you do not need to catch every possible exception in every single operation. Depending on your project size, you can even just use trial and error. Got a NullPointerException? Find out how to prevent your code from ever making a reference to a null object.

Jeremy Kato
  • 467
  • 5
  • 12
  • Trial and Error is actually good idea. However, as a technical person, we know how to use the system properly. However, if end-user tries to make crazy things and got some other exceptions. Is it a good practice to let the system down in such a case? – drJava Jun 03 '16 at 20:08
  • That's mostly dependent on what kind of errors to expect. Let's say you write a calculator application. A simple, potential error is the user entering something like a letter in the field instead of a number. Here, you could technically handle the exception - but at the same time, you could check your variables and ensure that there are no letters before your calculator continues. Obviously, it is nice to be able to catch literally everything, but generally speaking, if you can verify/validate whatever the user inputs before using it, then you don't have to worry. – Jeremy Kato Jun 03 '16 at 20:12
  • So, in summary - for inputs, either catch exceptions that the user can cause, or make sure to decline any input that can cause exceptions. For your internal functions that you know you can't throw exceptions for (ex. you make an object and you obviously don't need to check if it's null on the next line of your code), then you can get away without accounting for what are (*or should be*) impossible exceptions. – Jeremy Kato Jun 03 '16 at 20:15
0

1) operations will not undone. 2) best practice is to have all possible exception child class to exception class in try catch block so that if there no specific exception handler in beginning then Exception will handle the situation. It's good to have separate try catch block for each operation however the code will look to messy.

Anand Kulkarni
  • 87
  • 5