Full code in try / catch block

Question

I want to know if it is good practice place the complete code inside a try block or should I place only the code which I feel it will cause a specific exception ?
And should I usually use a basic exception

Code 1 : full code in try block

 myFunction(){ try{ ......... Code with chance of OneException ............. }catch(OneException e){ ............ }catch(Exception e){ .............. } } 

Code 2 : only code with probability of exception in try block

 myFunction(){ ....... try{ Code with chance of OneException }catch(OneException e){ ............ } ............ } 

Code 3 : should I always throw an exception

  myFunction(){ ....... try{ Code chance of OneException }catch(OneException e){ ............ }catch(Exception e){ .............. } ........ } 

From this (code1, code2 and code3), which one is better?
I mainly care about coding java and C ++

Answer 1

Generally speaking, you should only select exceptions that you are interested in and that you can handle . That is ... catch the exception where you can do something st the user does not perceive the problem or when it is clearly necessary to tell the user about the problem.
With all other exceptions, let them pop up with all their details (stacktrace, etc.), which you obviously go to the log. Note, obviously, this does not mean that the user should also see this exception output, but rather a general error.

I think this, I believe that when you write "Code chance of OneException", you know how to handle OneException, but not an exception, right? So then ... handle only one exception.

Answer 2

Always keep track of what you have, and no more. No matter how hard we try, we cannot make our code completely "idiotic proof." If someone gives you something that will lead to some random error, then it is their task to handle this. If our code handles someone else's exception, which has too much risk of being an unexpected side effect.

As for the code in which: the code before the line that can throw an Exception will be executed anyway, so it really doesn't make sense to have it inside the try block and before the code that throws. Code after a potential exception should be placed between try and catch if and only if it depends on the exception generation code. Thus, if the call to the database connection may fail, place all database queries inside the try block.

Limiting the "time" spent trying ... to catch makes it easier to read and less prone to accidental traps. I can’t say how many hours were lost because someone decided to catch the Exception, which was supposed to spread.

Answer 3

• a) It is bad practice to place the complete code inside a try block.

  • a1) In addition to catching exceptions, try-block is documentation in which an exception can occur. So put it close to the point, you mean.
  • a2) In bad circumstances, you have a file to read and add it later for writing, but your exception (FileNotFoundException) was only written at a glance. The hard volume around problem areas will help you identify further problems.

• b) Do not catch the basic exception for completeness or avoid multiple catch blocks. If you want to write to a file, many things can go wrong: There is no permission, an illegal file name, there is no space on the device .... If you present a general message to the user ("Could not write file" + name), he does not know , what to do. Be very specific, and you can tell him: "Only 20 MB left on the device" + devicename + "We need another 8 MB (28 MB in total), please free your space and try again or select another device!" ), If you catch the “Exception”, the chances are high that you think of some exception, but another happens and is not handled correctly, because the catch block was not written with this in mind. The best chance of finding this exception is to let it pop up or record it if the logs are monitored regularly.

This may be the difference between developing an application that is simply used by end users, or developing an API that is used by other developers. In the API, you often want to wrap an exception in your own exception to make it easier to work with your api, and if you have a single way to handle exceptions. If your code can throw a lot of exceptions and lead to an ugly client code where your client will have to specify a bunch of exceptions again and again, you often end the exceptions and reverse them:

 try { ... } catch {FileNotFoundException fnfe} { throw new MyApiException (fnfe); } catch {PermissionDeniedException pde} { throw new MyApiException (pde); } catch {IOException ioe} { throw new MyApiException (ioe); } 

This way, your client can decide how to handle the exception, and find the specific type of exception, if interested, inside your exception.

As Landei points out, in Java 7 there will be a simplified method to catch a few exceptions, but not just with a common superclass, see this link here

Answer 4

Wrap the code in a place where you really can handle the exception and where you can handle the error. If you cannot handle the error in the function, then do not wrap the code in the try / catch block.

I don't know for java, but in C ++ you have to catch the const link:

 try { // code that can throw an exception } catch ( const SomeExceptionType & error ) { // handle the error } 

Answer 5

C ++ is not Java or C # or ... where you need to catch (or finally ) clauses to clear after yourself. In C ++, RAII does this. Therefore, I rarely ever wrote try / catch try in C ++, to the extent that I consider this a code smell.

So, instead of looking at the code style that you should use in conjunction with try / catch , you should ask yourself if you need this try / catch at all.