Can I somehow have this block of code in a method
if (!printStackTrace_printed) {
ex.printStackTrace();
printStackTrace_printed=true;
}
logStoreException(ex);
throw new Exception(ex.getMessage());
and call it inside of each catch block and pass it the correct argument ex or npe
catch (RationalTestException ex) {
if (!printStackTrace_printed) {
ex.printStackTrace();
printStackTrace_printed=true;
}
logStoreException(ex);
throw new Exception(ex.getMessage());
}
catch (NullPointerException npe) {
if (!printStackTrace_printed) {
npe.printStackTrace();
printStackTrace_printed=true;
}
logStoreException(npe);
throw new Exception(npe.getMessage());
}
catch (Exception ex) {
if (!printStackTrace_printed) {
ex.printStackTrace();
printStackTrace_printed=true;
}
logStoreException(ex);
throw new Exception(ex.getMessage());
}
Since you're catching Exception in the last catch, and all catch blocks are identical, you can remove entirely the other two catch blocks without affecting the program.
The reason it doesn't make any difference is that NullPointerException is a subclass of Exception, so catching Exception will also catch NullPointerException and any other Exceptions thrown in the try block.
Note that in general, catching Exception is considered to be an anti pattern, except at the top most level of a server call.
You can only enter one of those catch blocks, not all of them, so you don't need the 'printStackTrace_printed' boolean at all. It's also poor practice to catch one exception and throw another in general but if you have a reason to do it at all, you only need to catch Exception, not the other two. So your question mostly disappears.
Related
I'm going through our code for our core programs to refactor and I encountered this weird try/catch block
try {
//Do some socket and network stuff
} catch (NoRouteToHostException e) {
throw e;
} catch (UnknownHostException e) {
throw e;
} catch (IOException e) {
throw e;
} finally {
//Does some counting stuff over here
}
Now I can't understand why on earth someone would do something like this, the people who wrote this code have left the company, but were indeed very skilled.
Is there a purpose to this try/catch block? Would it not be better to just throw these exceptions and do the finally things from where the method is called?
If you do literally nothing with the exception before you rethrow it, there is no point in catching it. Remove the catch block for that particular exception.
try doesn't need any catch blocks, provided there is a finally.
Note that catch (SomeException e) {} is doing something with the exception: it is swallowing it (which is likely not advisable anyway). As such, you cannot remove this without changing semantics.
The only exception (no pun intended) is if you don't want to catch a particular subclass of an otherwise-caught exception. For example:
try {
} catch (FileNotFoundException e) {
throw e;
} catch (IOException e) {
// Do something.
}
If you were to remove the catch/rethrow of FileNotFoundException, it would change the semantics because it would be handled by the more-general IOException. As written, a FNFE will "leap frog" the catch block for IOE.
(This is only very occasionally useful).
Either they didn't know they could write try-finally without catch or it's a legacy piece and it formerly performed something different for each catch block.
Otherwise, it makes no sense and it's identical to
try {
// Do some socket and network stuff
} finally {
// Does some counting stuff over here
}
Even skilled people tend to make mistakes, particularly when a deadline approaches.
If you throw every exception you catch, you will end up with an unhandled exception and your application will crash. At some point in your code, you will have to decide how you will deal with the error. If you are writing a GUI application this may be at the GUI layer, where you display an error message to your user. However, throwing all exceptions caught is no different to simply marking your method with throws IOException, ....
Also, since Java 7, you can use try-with-resources, for example:
try (Socket socket = serverSocket.accept()) {
socket.getInputStream() // whatever
} catch (IOException e) {
doSomething(e);
}
Note that you can still omit the catch block and simply pass the exception up to the enclosing scope.
Is it correct to catch everything into the main? If not, why?
public static void main(String[] args) {
try {
// A lot
// of
// calls
} catch (Exception e) {
e.printStackTrace();
}
}
Generally it's better to separate out the catches IMO, so that you can handle each separately even if you end up handling these the same. It's also easier to see what the risks are, what the catch is, when you come back to your code. Just a quick example:
try {
} catch (URISyntaxException e) {
e.printStackTrace();
} catch (IOException e) {
request.abort();
} finally {
client.close();
}
If all you do is call e.printStacktrace (), I do not think it is worthwhile. The JVM will do something like that anyway. But I believe it is worthwhile if you output a meaningful message; stacktraces are meaningful only to programmers.
It will catch every Exception from the try{} block, It might not catch if there is another catch catching in the inner code
It depends. If you only need to show some error messages when an exception arise, I guess it's ok. But if you find the need to make some kind of processing depending on the type of exception, then you'll be better off try-catching in the inner code.
In your case it makes no sense since you do not process the exception you catch but simply print it. If you declare main throws checked_exceptions_your_code_throws_list you will get the same result (JVM will print exception) and a cleaner code. And if your code throws no checked exception then do not declare any exceptions at all.
What is the difference between these usage of try-catch blocks and when you should use each one?
try {
doSomething1();
} catch(Exception e1){
exception_handle1();
}
try {
doSomething2();
} catch(Exception e2){
exception_handle2();
}
try {
doSomething1();
doSomething2();
} catch(Exception e1) {
exception_handle1();
} catch(Exception e2) {
exception_handle2();
}
try {
doSomething1();
try {
doSomething2();
} catch(Exception e2){
exception_handle2();
}
} catch(Exception e1){
exception_handle1();
}
try {
doSomthing1()
catch(Exception e1){
exception_handle1()
}
try {
doSomthing2()
catch(Exception e2){
exception_handle2()
}
doSomthing1() and doSomthing2() are unrelated methods. Failure of either one of them is independent on each other.
try {
doSomthing1()
doSomthing2()
catch(Exception e1){
exception_handle1()
}catch(Exception e2){
exception_handle2()
}
We can use the try-catch block this way to stop doSomthing2() method from executing if doSomthing1() fails. We can handle each exception individually with two catch blocks. But, one important point to note is that, your 2nd catch block is an unreachable code. In general, you should have catch block for more specific exceptions first, followed by generalized exception. Now, in your case, all the exception that 2nd catch block is supposed to handle will already be handled in the first one.
try {
doSomthing1()
try {
doSomthing2()
catch(Exception e2){
exception_handle2()
}
}
catch(Exception e1){
exception_handle1()
}
We have 2 try-catch blocks embedded in each other. Even after the doSomthing2() fails the program will continue inside the try block.
Well, the obvious difference between the first and the other two is that doSomthing2 will be attempted whether or not doSomthing1 threw an exception. In the exact code you quoted, there isn't a huge difference between the second and third examples (syntax errors aside) other than that in the third example, your exception handling code for the second try is within the exception handling code for the first, and so if it throws, the throw will be caught.
Which you should use depends entirely on the situation. Sometimes, it's appropriate to run doSomthing2 whether or not doSomthing1 throws an exception. Sometimes it isn't.
If doSomThing1 fails then the code moves on to execute doSomthing2
In the second example, doSomthing2 does not get executed if doSomthing1 fails
Whereas, third example is similar to second one.
First lets asume, doSomething1() and exceltion_handle1(), don't call System.exit(x) or something.
1) So first piece of code, will doSomething1(), no matter doSomething1() will throw any Exception or not, it will handle it (process the catch code block) and advance to second try and run it the same way.
try {
doSomething1();
} catch(Exception e1){
exception_handle1();
}
try {
doSomething2();
} catch(Exception e2){
exception_handle2();
}
It's morning, so I hope I won't make any wrong decisions.
2) This code will run doSomething1() then doSomething2(), and no matter which one will fail (throw Exception), only first catch clause will be called, as it absorbs all the subclasses and itself, so second catch won't be reached (first takes all the possible exceptions).
So afaik, you should get an error (shouldn't compile). It's smart and will recognize, that second catch won't be reached in any way.
The correct pattern would be : as we go to the bottom, exceptions should be broader and broader (strictly). It's logical, as order of catching clauses goes down, upper catch shouldn't be parent of bottom ones, as ANYWAY parent will take that exception, and childs in the bottom won't be reached.
Example: (I recommend you to learn about Multicatch in java.)
catch (Specific2ChildOfSpecific1 e3)
...
catch (specific1ChildOfException e2)
...
catch (Exception e1)
try {
doSomething1();
doSomething2();
} catch(Exception e1) {
exception_handle1();
} catch(Exception e2) {
exception_handle2();
}
3) This one: If doSomething1() will fail e1 catch clause will be executed and thats all, if it will pass, then if doSomething2() will run and if it fails, then e2 catch clause will be executed.
Notice # second example, no matter which doSomething will fail, e1 will be executed (don't forget there is an error as second is unreachable). But I understand what you wanted to ask.
try {
doSomething1();
try {
doSomething2();
} catch(Exception e2){
exception_handle2();
}
} catch(Exception e1){
exception_handle1();
}
its the same concept when you creating a conditionaL statement, just that conditionaL statement is testing the condition the try catch is testing an error
In Java, is there any way to get(catch) all exceptions instead of catch the exception individually?
If you want, you can add throws clauses to your methods. Then you don't have to catch checked methods right away. That way, you can catch the exceptions later (perhaps at the same time as other exceptions).
The code looks like:
public void someMethode() throws SomeCheckedException {
// code
}
Then later you can deal with the exceptions if you don't wanna deal with them in that method.
To catch all exceptions some block of code may throw you can do: (This will also catch Exceptions you wrote yourself)
try {
// exceptional block of code ...
// ...
} catch (Exception e){
// Deal with e as you please.
//e may be any type of exception at all.
}
The reason that works is because Exception is the base class for all exceptions. Thus any exception that may get thrown is an Exception (Uppercase 'E').
If you want to handle your own exceptions first simply add a catch block before the generic Exception one.
try{
}catch(MyOwnException me){
}catch(Exception e){
}
While I agree it's not good style to catch a raw Exception, there are ways of handling exceptions which provide for superior logging, and the ability to handle the unexpected. Since you are in an exceptional state, you are probably more interested in getting good information than in response time, so instanceof performance shouldn't be a big hit.
try{
// IO code
} catch (Exception e){
if(e instanceof IOException){
// handle this exception type
} else if (e instanceof AnotherExceptionType){
//handle this one
} else {
// We didn't expect this one. What could it be? Let's log it, and let it bubble up the hierarchy.
throw e;
}
}
However, this doesn't take into consideration the fact that IO can also throw Errors. Errors are not Exceptions. Errors are a under a different inheritance hierarchy than Exceptions, though both share the base class Throwable. Since IO can throw Errors, you may want to go so far as to catch Throwable
try{
// IO code
} catch (Throwable t){
if(t instanceof Exception){
if(t instanceof IOException){
// handle this exception type
} else if (t instanceof AnotherExceptionType){
//handle this one
} else {
// We didn't expect this Exception. What could it be? Let's log it, and let it bubble up the hierarchy.
}
} else if (t instanceof Error){
if(t instanceof IOError){
// handle this Error
} else if (t instanceof AnotherError){
//handle different Error
} else {
// We didn't expect this Error. What could it be? Let's log it, and let it bubble up the hierarchy.
}
} else {
// This should never be reached, unless you have subclassed Throwable for your own purposes.
throw t;
}
}
Catch the base exception 'Exception'
try {
//some code
} catch (Exception e) {
//catches exception and all subclasses
}
You may catch multiple exceptions in single catch block.
try{
// somecode throwing multiple exceptions;
} catch (Exception1 | Exception2 | Exception3 exception){
// handle exception.
}
It is bad practice to catch Exception -- it's just too broad, and you may miss something like a NullPointerException in your own code.
For most file operations, IOException is the root exception. Better to catch that, instead.
Do you mean catch an Exception of any type that is thrown, as opposed to just specific Exceptions?
If so:
try {
//...file IO...
} catch(Exception e) {
//...do stuff with e, such as check its type or log it...
}
Yes there is.
try
{
//Read/write file
}catch(Exception ex)
{
//catches all exceptions extended from Exception (which is everything)
}
This may seem like a programming 101 question and I had thought I knew the answer but now find myself needing to double check. In this piece of code below, will the exception thrown in the first catch block then be caught by the general Exception catch block below?
try {
// Do something
} catch(IOException e) {
throw new ApplicationException("Problem connecting to server");
} catch(Exception e) {
// Will the ApplicationException be caught here?
}
I always thought the answer would be no, but now I have some odd behaviour that could be caused by this. The answer is probably the same for most languages but I'm working in Java.
No, since the new throw is not in the try block directly.
No. It's very easy to check.
public class Catch {
public static void main(String[] args) {
try {
throw new java.io.IOException();
} catch (java.io.IOException exc) {
System.err.println("In catch IOException: "+exc.getClass());
throw new RuntimeException();
} catch (Exception exc) {
System.err.println("In catch Exception: "+exc.getClass());
} finally {
System.err.println("In finally");
}
}
}
Should print:
In catch IOException: class java.io.IOException
In finally
Exception in thread "main" java.lang.RuntimeException
at Catch.main(Catch.java:8)
Technically that could have been a compiler bug, implementation dependent, unspecified behaviour, or something. However, the JLS is pretty well nailed down and the compilers are good enough for this sort of simple thing (generics corner case may be a different matter).
Also note, if you swap around the two catch blocks, it wont compile. The second catch would be completely unreachable.
Note the finally block always runs even if a catch block is executed (other than silly cases, such as infinite loops, attaching through the tools interface and killing the thread, rewriting bytecode, etc.).
The Java Language Specification says in section 14.19.1:
If execution of the try block completes abruptly because of a throw of a value V, then there is a choice:
If the run-time type of V is assignable to the Parameter of any catch clause of the try statement, then the first (leftmost) such catch clause is selected. The value V is assigned to the parameter of the selected catch clause, and the Block of that catch clause is executed. If that block completes normally, then the try statement completes normally; if that block completes abruptly for any reason, then the try statement completes abruptly for the same reason.
Reference:
http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#24134
In other words, the first enclosing catch that can handle the exception does, and if an exception is thrown out of that catch, that's not in the scope of any other catch for the original try, so they will not try to handle it.
One related and confusing thing to know is that in a try-[catch]-finally structure, a finally block may throw an exception and if so, any exception thrown by the try or catch block is lost. That can be confusing the first time you see it.
If you want to throw an exception from the catch block you must inform your method/class/etc. that it needs to throw said exception. Like so:
public void doStuff() throws MyException {
try {
//Stuff
} catch(StuffException e) {
throw new MyException();
}
}
And now your compiler will not yell at you :)
No -- As Chris Jester-Young said, it will be thrown up to the next try-catch in the hierarchy.
As said above...
I would add that if you have trouble seeing what is going on, if you can't reproduce the issue in the debugger, you can add a trace before re-throwing the new exception (with the good old System.out.println at worse, with a good log system like log4j otherwise).
It won't be caught by the second catch block. Each Exception is caught only when inside a try block. You can nest tries though (not that it's a good idea generally):
try {
doSomething();
} catch (IOException) {
try {
doSomething();
} catch (IOException e) {
throw new ApplicationException("Failed twice at doSomething" +
e.toString());
}
} catch (Exception e) {
}
No, since the catches all refer to the same try block, so throwing from within a catch block would be caught by an enclosing try block (probably in the method that called this one)
Old post but "e" variable must be unique:
try {
// Do something
} catch(IOException ioE) {
throw new ApplicationException("Problem connecting to server");
} catch(Exception e) {
// Will the ApplicationException be caught here?
}