Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Could not find or load main class com.mindprod.ensure.Ensure Date: Tue, 14 Jun 2016 10:33:55 -0000 (UTC) Organization: A noiseless patient Spider Lines: 47 Message-ID: References: <64htlb5ikduodj9qr700ob3tqbulribl5a@4ax.com> <58be2264-bf4a-4da1-a6b2-8501e9daf435@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 14 Jun 2016 10:33:55 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="15335"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gR5IQZ0i0P5O4jV/9AWgkJqOWClFGMh8=" User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 3663720 git://git.gnome.org/pan2) Cancel-Lock: sha1:NbHmfGJzDpBpuLMbarlC8OeBHXc= Xref: csiph.com comp.lang.java.programmer:34628 On Mon, 13 Jun 2016 22:58:44 -0400, Eric Sosman wrote: > What should the main() of a GUI application do if something > further down the line throws HeadlessException? > > Okay, that's a RuntimeException and perhaps we could fix the > wording to prohibit only the checked exceptions. But even so: If main() > catches an InterruptedException from something further down, what action > can main() take that would be better than just letting the IE propagate > outward? > > public static void main(String[] args) { > try { > // "payload" of main() > } catch (InterruptedException ex) { > LOGGER.severe("I was interrupted!", ex); > Thread.currentThread().interrupt(); > // now what? > } catch (Exception ex) { > LOGGER.severe("I'm thrown for a loss!", ex); > // now what? > } > } > > What "constructive" or "useful" steps could be taken in the catch blocks > that would be "better" than letting main() throw the Exception? > In situations where there *is* something better, well sure: Do the > better thing. But is it a given that something better is possible? > Your code summarises it pretty nicely. All I'd add is that the user needs to know what happened, so if the program uses GUI interface it should log the error[1] and report it to the user using a JOptionPane or similar. If its a command-line (headless) program it should log the error[1] and inform the user by writing one or more lines to System.err. In both cases it can simply terminate after its reported what happened. [1] logging the error is a good idea on systems that support a central logging system and can be skipped when running on a system that doesn't. The benefit of logging the error as well as telling the user is just that the sysadmin has a sporting chance of finding out what really happened if the user either doesn't tell anybody or gives a garbled report. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |