CODEWITHSUNDEEP
javaexception
punkconvoy
punkconvoy

Reputation: 41

Why Would you catch Throwable and do nothing but print a stack trace?

I have tried looking for an answer to this on other threads, but so far I have only seen threads that state that catching Throwable is bad. My question is, is there ever a reason why you would WANT to do this and then do nothing in the catch block except print out the stack trace?

I was recently brought onto a project and given the task of cleaning up the error handling of an existing set of classes for a RESTful service. Several of the helper service classes have try/catch blocks that only catch Throwable and print out the stack trace, as shown below:

class MainService {

  SubService1 s1;
  SubService2 s2;

  public doMainService() {
  }

}


class SubService1 {

  public int findSomething() {

    try {
        // Do Something
    } catch (Throwable t) {
        t.printStackTrace();
    }
  }
}

class SubService2 {

  public int findSomethingElse() {

    try {
        // Do Something
    } catch (Throwable t) {
        t.printStackTrace();
    }  
  }

}

Is there a case that this is acceptable? Would it be better for the methods to throw Exception and not have the try/catch blocks?

Upvotes: 3

Views: 3443

Answers (7)

jtahlborn
jtahlborn

Reputation: 53694

Never do this (e.printStackTrace()). many IDE's default to it, but its horrible (many apps run with stderr redirected in ways that are not accessible, and thus, never seen). rules of thumb:

  • if you truly don't care about the exception (never, ever, ever, ever will care), catch it and do nothing with a big comment which says "we really, really don't ever care if this exception gets thrown"
  • if you never expect an exception to actually be thrown (the interface defines a checked exception, but you know the impl doesn't actually throw it), rethrow the exception as something like new UnsupportedOperationException("this should never happen", t) (that way if/when the underlying impl gets changed you find out about it sooner rather than later)
  • if you expect that the exception is unlikely, and you usually will not care about it, log it with a proper logging infrastructure (log4j, commons logging, or java.util.logging). that way it will most likely make it somewhere that you can see later if you decide that you actually do care about the exception after all.

Upvotes: 0

Eshan Sudharaka
Eshan Sudharaka

Reputation: 607

Most simplest example we come across in your problem is when it comes to close an input stream.Follwoing is the method declaration in InputStream class.

public void close() throws IOException

Althoug there is a possiblity to throw an exception when we call this method it would be no harm for the program execution.(Since we will not use that InputStream further) In that case we should only log the error and continue the program. But if you find out an exception which change the states of an object and then you must think about recovery code or halt execution.

Upvotes: 0

Adam Zalcman
Adam Zalcman

Reputation: 27233

This is almost never a good practice for a variety of well known reasons.

In particular, it doesn't distinguish between checked and unchecked exceptions and errors. More importantly, one of the effects of this code is allowing the application to execute beyond the exception handler which may result in all kinds of strange behavior due to violated invariants. In other words, since the exception caught may be really anything including violated assertions, programming errors, thread interruptions, missing classes, I/O errors, OOM conditions and even library and VM bugs, the program state is practically unpredictable beyond the exception handler.

In some rare situations broad exception handling may make sense. Imagine a server handling multiple independent requests. You may not want to crash due to a problem encountered while serving one of the requests. Since you do not rely on the state left after the exception handler, you can simply print the stack trace and let someone investigate while the server continues serving other requests.

Even in these situations one should carefully consider whether errors, e.g. VirtualMachineError should really be caught.

Upvotes: 4

Trevor Freeman
Trevor Freeman

Reputation: 7242

It is possible that they wanted to see the stack trace without crashing the program.

For example it can be appropriate for code executed by a thread to log exceptions but otherwise do nothing when it is unacceptable for the thread to crash since the next iteration (say where threads are taking items from a queue) may work as expected. This depends on the use case, but for a server you generally want the threads to be bullet proof and log any errors, instead of halting any further processing (but use cases may vary).

Upvotes: 0

scaryrawr
scaryrawr

Reputation: 867

One reason that I think people do this is just because Java forces you to either surround calls that throw with a try/catch block, or add throws to the method declaration.

If you "know" that you're not going to have an exception occur, then it's kind of a way to prevent it from going up the chain (cause if you do throws, who ever calls your code needs to surround with a try/catch and so on), but if something does occur it'll dump it without crashing.

Upvotes: 2

Scape
Scape

Reputation: 59

I use it to see exactly where my program is crashing. So basically just for debugging. Also just to see if it's flowing in the way expected.

Upvotes: 0

mah
mah

Reputation: 39847

You might do that if you don't know any other way to get the stack trace and you want to know how you got to your current location. Not a very good reason, but a possible one. This doesn't seem to fit what you're looking at though; you seem to have been given code which doesn't crash but also doesn't do a good job with error handling.

Upvotes: 0

Related Questions