5
\$\begingroup\$

I have a program that has to initialize a few big things (connect to a few databases, parse some XML) and without the initialization being successful the program would not be able to continue.
Right now I have my main method throwing just a general Exception

public static void main(String[] args) throws Exception
{
    //Throws numerous types of Exceptions
    WhateverObject we = WhateverObject.getInstance();

    we.doSomething();
}

My question is, is there a better way to handle this? Should I catch the exception and then print out that it failed an exit? Something else maybe? Note, there's no hope of program recovery at this point.

\$\endgroup\$

2 Answers 2

Reset to default
2
\$\begingroup\$

For many (small) applications, what you are doing is OK. Not great, but OK.

The problems come with the following:

  1. exception traces will be printed to STDERR (the console, not a file). If the console output is discarded, the error is lost (eg. .... >& /dev/null)
  2. the exit code of the application may or may not be set to an error code
  3. if one of your sub-systems succeeds before another one fails, and it starts a non-daemon thread, then your application may not even terminate at all.

For any robust application I recommend using an uncaught-exception handler. This handler should log the uncaught exception to a logical place, and it should System.exit(1) (or some other exit code).

This may complicate things with threads that do not trap their exceptions, but that is bad pracitce as well....

See the documentation for the uncaught exception handler, and some tutorials.

\$\endgroup\$
1
  • \$\begingroup\$ As of now, the console output should go to a file (the library I'm using for my FastCGI interfacing routes all System.err to the Apache log file but only if it's be initialized and System.out to the webserver to display to the client). The application is also single-threaded but that may change. For now I'll catch the exceptions and exit and I'll use the handler if it becomes multi-threaded. Thank you :) \$\endgroup\$
    – Cobertos
    Commented Mar 18, 2014 at 20:09
2
\$\begingroup\$

  1. What would the users like? It's usually an error message and a log file with the details and stacktraces for bug reports/support calls/debugging. You can throw exceptions out from main but it's not user-friendly (unless the users are the people who develop the software).

  2. Please note that singleton nowadays is rather an antipattern. (WhateverObject.getInstance() looks like a singleton.) They make testing harder and often hide dependencies which leads to spaghetti code which is really hard to work with.

\$\endgroup\$
1
  • \$\begingroup\$ The users would just be me and the code maintainers as this is a backend prototype of a system so I think a log file will suffice. As for the singleton, I am actually using a singleton. The main arguments seem to be the coupling (new term for me) and for testing (I've never actually done formal unit testing before) where I can really see the appeal of not having a singleton pattern. Thanks for the info :D. I'll keep this in mind the next time I'm looking at a singleton pattern. \$\endgroup\$
    – Cobertos
    Commented Mar 18, 2014 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.