Unchecked Exceptions thrown in a GUI Application

We know that unchecked exceptions are to use in case of violation of the contract of a method. If the application is running in a console, the exception will appear in the console window, along with its stack trace. This is true even for GUI application (say written in Swing) invoked from a console and console is running in the background.

But, what will happen if the GUI application does not have a console? E.g User double clicks on a link and the application directly starts, without any console in the background. Where will the un-handled unchecked exceptions go?

The reason for this question is some developers try to justify catching unchecked excepti开发者_JS百科ons based on the above scenario.

As mentioned by others, unchecked exceptions will go to stderr, which goes nowhere when no console is present. Your best bet is to install a new default exception handler and then log the exception or present an error message to the user. Note than an exception handler can be installed on all threads, or on a particular thread, e.g. the UI thread.

I believe that exceptions thrown by the GUI thread, which cannot go to a console, are outright discarded. They don't go anywhere.

Also, unchecked exceptions are definitely not necessarily "to use in case of violation of the contract of a method". There's a lot of controversy on this subject - when to use checked and unchecked exceptions and why, why you would or would not want to catch exceptions, etc. This is even more complicated when considering calls to other libraries, calls into the Java libraries, etc. You may also want to do something with even an unchecked exception. (For example, the parsing methods in Java's Number classes throw unchecked exceptions that you almost certainly want to catch.)

I would always catch even unchecked exceptions from the GUI thread somewhere, because it's much more user-friendly to display a useful dialog box than to have an exception show up on the console. Exceptions are for developers, not users. In Java there is a special mechanism for doing this that will allow you to catch all GUI exceptions and do something constructive with them before they hit the console. You can call Thread.setDefaultUncheckedExceptionHandler() to set the default method for handling unchecked exceptions in all threads, and also call System.setProperty("sun.awt.exception.handler", "string-that-names-exception-handler-class") so that the system will pass exceptions to the class of your choice. As far as I can remember, the class for both of those needs to implement Thread.UncaughtExceptionHandler.

EDIT: Credit to AKF and others, they do go to stderr. The problem is that typical methods of launching GUI apps don't involve redirecting stderr to a file; stderr and stdout are just discarded. What I would strongly recommend is using a logging facility of some sort and then logging, not only the exceptions, but other interesting things that happen in your code. For example, I set up a primitive logging facility for some research code of mine so that it would log when it starts certain algorithm code, how long it takes, which experimental case it's on, etc. However for production code I'd probably want to take the time to learn and use a real logging facility such as log4j, java.util.logging, or whatever else people are using these days.

If they are thrown typically they go to stdout, which is ignored by the OS if a console or pipe is not present.

These unchecked Exceptions will still be written to stderr. For this reason it is useful to redirect stderr (and stdout) to a file.

On OS X, error messages in GUI applications are appended to a system log, viewable in the Console application. I don't know whether this happens specifically for exceptions in Java applications, but I imagine so and it is easy to test if you have any of them.

I don't know about other operating systems.

I agree with the other posters that you should redirect them to a file yourself.