Catching some exceptions but ignoring others - why doesn't this work?

Question

I have something similar to this.

void func() {
  try {
    //socket disconnects in middle of ..parsing packet..
  } catch(Exception ex) {
   if(!ex.getMessage().toString().equals("timeout") || !ex.getMessage().toString().equals("Connection reset")) {
     debug("Exception (run): " + ex.getMessage());
     ex.printStackTrace();
  }
}

Why is it that when I get a connection reset exception or a timeout exception, it still goes inside the condition. I tried without toString and with no luck.

Cohla

Answer 1

You shouldn't catch all exceptions and then test the error message of the exception. Instead only catch those exceptions that you intend to handle - for example SocketTimeoutException.

catch (SocketTimeoutException ex)
{
    // Do something...
}

With your current code you may be catching some other type of exception that you weren't expecting. Currently you will just ignore this exception, not even logging it. This can make it very difficult to debug what is going on. If you have an exception that you can't handle you should either rethrow it or log it.

I want to catch all exceptions

If you really want to do that then you can write your code as follows:

catch (SocketTimeoutException ex)
{
    // Do something specific for SocketTimeoutException.
}
catch (Exception ex)
{
    // Do something for all other types of exception.
}

---

Regarding your specific error, you have written:

!a.equals(b) || !a.equals(c)

This expression always evaluates to true. What you meant was:

!a.equals(b) && !a.equals(c)

Or equivalently:

!(a.equals(b) || a.equals(c))

Note that by rewriting your code as I suggested above you completely avoid having to write this complicated boolean expression.

Albatross

Note: You could also add an else block that rethrows the exception, but that should be a last resort if it's impossible to prevent catching just the exceptions you need to catch – Hedges

I want to catch all exceptions (even those that i forgot) thats why i left this code in as it's in very far alpha stage and I don't know what might happen. I'm trying to Ignore SocketTimeOutException and others.. yet I want full support for any missed exceptions – Cohla

SSpoke if this is in the early stages of testing you should not be catching any exceptions at all as you will want to see every possible fail point immediately – Galyak

@SSpoke: If you really want to do that, you can add a catch (Exception ex) block after the other catch blocks. But don't just swallow the exceptions without logging - that's about the worst thing you can do. – Albatross

It's a server if it fails it may jump out of a thread and completely screw up. So exceptions are built-in to break out of inner loops and such. Like while it's waiting for the full packet to arrive a connection could be lost so I throw a custom exception timeout as a built-in behavior – Cohla

Well why is it that I cannot use that if condition? it's like ignoring it altogether? I mean i can do System.out.println("|"+ex.toString+"|"); and it will output |timeout| yet ex.toString().equals("timeout") == false?? why? – Cohla

Ah i see I forgot the bitwise brackets. I'll give your exception idea a try first if it doesn't work out too well I'll do the brackets thanks. – Cohla

Answer 2

It's really not safe to rely on exceptions messages to know what is the cause of your exception.

In your case you can try to catch more specific exceptions, such as SocketTimeoutException and the classic IOException :

void func() {
    try {
        //socket disconnects in middle of ..parsing packet..
    } catch(SocketTimeoutException ex) {
        //In case of Time out
    } catch(IOException ex){
        //For other IOExceptions
    }
}

Sources :

[Socket.connect()][3]

Even if you prefer to seek informations in exceptions messages, you shouldn't check if the message simply is equal to "timeout" but if the message contains "timeout"

[3]: http://download-llnw.oracle.com/javase/6/docs/api/java/net/Socket.html#connect(java.net.SocketAddress, int)

Lynnet

Alright I'm understanding a little bit.. so your saying i should add a ton of blank catch exceptions above.. which will act as avoiding conditions. and the final catch(Exception ex) with no conditions? and if some exception is useless try to find out what it is and add it to blank too? Problem is.. it's generating logs in my CentOS server in 24 hours which are extremely big (200 mb) and i want to keep only fresh exceptions which i never seen before for fixing purposes – Cohla

No, I'm saying that you should catch the IOException you need to get of the logs and treat them apart, then after all of this you can catch all other exceptions and log everything. – Lynnet