How are un-checked exceptions reported to the user

Since there is no need to try/catch or specify un-checked开发者_StackOverflow exceptions, how are they are reported to the user?

how are they are reported to the user? What is the best practice to handle un-checked exceptions?

In our application, we barely use any exception at all: neither checked nor unchecked (we consider checked exceptions to be a Java idiosynchrasy unrelated to the problem domain we're dealing with, so we wrap most checked exceptions inside cleaner APIs, using state testing methods).

The way we deal with it is simple: it's a desktop application, if we catch an uncaught exception, we offer the user the possibility to send us a report. All the user has to do is click on "Report" and we get the full stack traces and other infos sent to one of our servers.

You can set up an application-wide uncaught exception handler like this:

Thread.setDefaultUncaughtExceptionHandler( new Thread.UncaughtExceptionHandler() {
    public void uncaughtException( final Thread t, final Throwable e ) {
       ...
       // Here we offer our user the possibility to 'report' the exception, YMMV
    }
 }

Typically there are zero exception happening in our software: we don't use checked exception for flow control (unless when we're using brain-dead APIs from the nineties, where this was common practice).

Some frameworks, like Spring, also have a pretty strong preference towards the "no checked exceptions" mentality.

So exceptions for us are really exceptionnal, hence the popup warning the user that the app crashed and offering them the possibility to send us the report.

If you are writing a container or a framework or a UI framework, then the best place to handle them is centrally, propagate them all the way to central handler and report the error to user in a usable way, If using a UI, provide a way for user to report that exception.

Details:

We generally use a practice when using UI is that have a central exception handler. In case of a web UI, we have on handler that shows the user that something has gone wrong in the system, The error page also has a form with hidden fields that has stack trace along with a description (optional) field asking the user to describe what she/he was doing when error occured. The for submits the error information, with stacktrace to the system (which can be a mail or simply stored in db) In a desktop UI, could be the same, only thing that will be different is where you put your exception handling code.

Error reporting example

Error reporting example http://www.flickr.com/photos/aniketn/4785197367/

You actually can catch unchecked exceptions. It's just that they're usually things you can't solve when you do catch them - for example, NullPointerException. There's generally not a way to smoothly and gracefully resume whatever you were doing when the NullPointerException occurred.

If you don't handle them, they will propagate all the way up through your program and it will abort, dumping a stack trace of the exception.

The best practice is to deal with the ones where you can provide some better handling than the default. For example, if you call an external library function, you could wrap it in a try/catch block and if the library throws a NullPointerException you could give the user a friendly error message (a GUI "library X failed to do Y - did you specify a valid Z?") instead of a stack trace on the command line. But in the general case, the reason they're unchecked is because even if you knew about them, there'd be nothing for it but to throw up your hands.

When bubbling out of the main(...) method, the JVM prints the stack trace to System.out and exits that thread. For single-thread programs, that would also exit the program.

In general, every thread you run should have a wrapper catching Throwable so you can at least log it to your files.