无法处理的Java异常

Question

I frequently come across the same problem. At the very core of my Java Application, I have methods that throw an exception which cannot be handled by any method caller. I have to bubble those exceptions up to the main method. All those exception summarize so I have many throws statements on higher levels of my Application.

Eg I have a NodeJsManager.java class at the core of my application:

public class NodeJsManager {

    public static void startNodeJs() throws ExecuteException {
        // Code to start NodeJs Server goes here
    }

}

To start the NodeJs Server, I have to execute something on command line. I can do that with the apache class org.apache.commons.exec.CommandLine . But it throws an ExecuteException, if the execution exited with an error code. Without NodeJs being started my application is useless. No method can catch this exception, it is just a requirement for my application to work. So the exception will bubble up almost the whole application lifecycle. I have other Managers that do the same (a ConfigurationManager that throws an exception, if the config path is wrong). All together it summarizes in many throws statements at every single method on a higher level where I don't even remember the cause of that exception.

How would you handle that problem? I must do something completely wrong because I can't find similar posts that describe my problem!

Regards Mike

Update

I just unearthed my good old Effective Java book. The Author (a Java architect at Google) wrote the following about Exceptions:

... use checked exceptions for recoverable conditions and runtime exceptions for programming errors.

...

If it isn't clear whether recovery is possible, you're probably better off using an unchecked exception ...

In my case it is clearly not recoverable, so throwing a runtime exception is the way to go. I always thought runtime exceptions should be prevented, this changes my point of view about exceptions in Java.

Answer 1

One possible approach is to deal with the Exception as close as possible to where it originated, where you have enough information to make a decision on what to do.

As you said if you have all the Exception s caught at the highest level possible you are losing the context which is really important, because that gives information on why and how the problem occurred (and hopefully a few ways to fix it).

You said for example that your application without a NodeJS server is useless, then probably a way of doing this would be to have the NodeJSManager (if such a thing exists :D, I'm guessing) to not throw, but prevent the application from starting at all, something like

NodeJSManager nodejsManager = new NodeJSManager();
boolean succeeded = nodejsManager.tryToStart();
if (!succeeded) {
    // guard, it's useless to proceed
    // cleanup and exit
}

I called that method tryToStart because it can happen that the server does not start, you are dealing directly with the executables and the file system so I would say this is not so exceptional any more (but probably this is just a matter of taste).

What's important IMHO is that you specify your application start up as a series of checks, for example the node and the configuration ones, without having to deal with Exception s to handle the flow of your code.

Answer 2

I don't like checked Exceptions. What I use to do (but is NOT a nice solution) is to catch the checked Exception and re-throw it as a Runtime Exception this way:

catch (ExecuteException e) {
    throw new RuntimeException (e);
}

The checked Exception "e" is passed as an parameter to RuntimeException. This way, I convert a checked into an unchecked exception. But as I said, is not a nice solution and it may cause more debugging problems that it solves. When an Exception is "checked" it tends to be because the error described is "serious".

Answer 3

One solution would be to create your own, more general exception class that will extends Exception and wrap unhandled exceptions as causes into your own exception. This way you can at least reduce some exceptions from methods signatures. example:

Create new class StartupException or ConfigurationException and throw it with the main exception after catching it as cause during startup phase.

Moreover if you would make StartupException extends RuntimeException) you would not have to declare such exception.

Another way would be to wrap everything into RuntimeException

If abowe does not suit your needs than this is probably design flaw, (if you really cannot handle it) that you will have to deal with it.