Why do exception fault Strings differ on different environments?

I have this snippet of code to deal with catching particular exceptions

private static final String CONNECTION_REFUSED_EXCEPTION = "java.net.ConnectException: Connection refused: connect";
...
} catch (org.apache.axis.AxisFault af) {

            if (af.getFaultString().equals(CONNECTION_REFUSED_EXCEPTION))
            {
               // Do something
            }
}

This works fine locally on my windows development environment

However, when I deploy to a unix machine for testing, the fault string differs, as show below (note the : connect missing from the end)

• Windows fault string : java.net.ConnectException: Connection refused: connect
• Unix fault string : java.net.ConnectException: Connection refused

Why is this so?

For the record, I believe the following would be better suited f开发者_StackOverflow中文版or matching the fault string :

...
if(af.getCause() instanceof java.net.ConnectException)
...

---

The 'fault string' messages are meant to provide additional information for debugging purposes. They can vary in different implementations, versions, or environments. The same applies in general to all Exception message strings (Throwable.getMessage()).

Application code should not rely on the exact text of Exception messages in order to identify the cause of the exception. Your suggestion of using instanceof instead to check the cause of the exception is a much better solution.

Edit:

If you absolutely need to check the detail message, as it seems to happen in your case (because getCause() is returning null), then I would recommend to check whether the detail message contains the name of the specific wrapped exception you are checking for (e.g. java.net.ConnectException). This is after all the same information you would be getting if getCause() wasn't returning null in the first place, and should minimize dependencies with the exact text of the detail message.

---

Many reasons:

1. Exception message Strings are not standardized.
2. Some exception messages include messages provided by the host operating system. These are likely to vary from one OS to another, and there's not much Java can do about it.
3. Exception messages originating from Java could be changed from one version to the next to clarify their meaning, etc.
4. Some exception messages originating from Java could be locale specific. (I don't think that this applies to the standard class libraries, but I could be wrong.)

In general, it is a bad idea for an application's error recovery code to rely on specific exception message strings. If you find that you have no choice, then make sure that you embed the code that contains the message string dependencies in a plugin class (or similar) so that you can easily a different version for the different OS platforms your application runs on.

---

What's the JVM on Windows and Unix? If they're not from the same vendor (Sun for example), the fault string could differ a bit.

---

The original fault string is (maybe?) coming from the apache axis library. Double check, if you use the same library version on both machines (the strings may vary accross versions). Another reason is "localization". Some fault strings are localized and may be different on machines with different locale settings. I'd check that too.