Question

I have a kludgey use of Java RuntimeError in which I fully handle the error. Only problem is it gives me annoying trace telling me where the runtime error that I derived and threw occurred. How to suppress this trace?

For reference, the issue is I subclassed a non-throwing class and needed my subclass to throw. It was either “rewrite my program to read like a C program” or “use runtime error to bypass throw specification requirement.” Obviously I’m finding the throw spec requirement very counterproductive right now – other workarounds that don’t involve maintaining a bunch of “workIsDone” variables would be appreciated.

Answer 1

Without code it’s awfully hard to know what you’re talking about, but in general, stack traces come from a handler catching an exceptions and calling printStackTrace() on it. The stack trace doesn’t appear unless something asks for it. Now, if an exception makes it all the way to the top of (for example) the AWT event thread stack, then the default handler will print it out this way.

As a rule, you want to handle exceptions. It can be a fine strategy to use runtime exceptions to get around the fact that some superclass method doesn’t declare any exceptions, but then you take responsibility for always catching those exceptions. If you can’t — i.e., if some other code is going to catch them instead — then this is a bad strategy and you can’t use it.