Should java try blocks be scoped as tightly as possible?

by

The basic premise here is false: the size of a try block makes no difference in performance. Performance is affected by actually raising exceptions at runtime, and that’s independent of the size of the try block.

However, keeping try blocks small can lead to better programs.

You might catch exceptions to recover and proceed, or you might catch them simply to report them to the caller (or to a human, via some UI).

In the first case, failures from which you can recover are often very specific, and this leads to smaller try blocks.

In the second case, where an exception is caught so that it can be wrapped by another exception and re-thrown, or displayed to the user, small try blocks mean that you know more precisely which operation failed, and the higher-level context in which that call was made. This allows you to create more specific error reports.

Of course, there are… exceptions (sorry!) to these guidelines. For example, in some cases very specific error reports could be a security problem.

It might be useful to know what effect a try block has on the compiled code. It doesn’t change the compiled instructions at all! (Of course, the corresponding catch block does, since it’s like any other code.)

A try block creates an entry in the exception table associated with the method. This table has a range of source instructions counters, an exception type, and a destination instruction. When an exception is raised, this table is examined to see if there is an entry with a matching type, and a range that includes the instruction that raised the exception. If it does, execution branches to the corresponding destination number.

The important thing to realize is that this table isn’t consulted (and has no effect on running performance) unless it’s needed. (Neglecting a little overhead in the loading of the class.)

More Related Contents:

  1. What causes a java.lang.ArrayIndexOutOfBoundsException and how do I prevent it?
  2. What is a StackOverflowError?
  3. How do you assert that a certain exception is thrown in JUnit 4 tests?
  4. Why do I get “Exception; must be caught or declared to be thrown” when I try to compile my Java code?
  5. Returning from a finally block in Java
  6. Concurrent Modification Exception : adding to an ArrayList
  7. java.rmi.ServerException: RemoteException occurred in server thread (ClassNotFoundException)
  8. Differences between Exception and Error
  9. What could cause java.lang.reflect.InvocationTargetException?
  10. Can constructors throw exceptions in Java?
  11. Why doesn’t Java allow to throw a checked exception from static initialization block?
  12. Why is exception.printStackTrace() considered bad practice?
  13. Why does division by zero with floating point (or double precision) numbers not throw java.lang.ArithmeticException: / by zero in Java
  14. StringBuilder/StringBuffer vs. “+” Operator
  15. tomcat server fails to start the server and application in STS [duplicate]
  16. Can we use “return” in finally block [duplicate]
  17. In a Java 7 multicatch block what is the type of the caught exception?
  18. Rethrowing exceptions in Java without losing the stack trace
  19. How can I catch Event Dispatch Thread (EDT) exceptions?
  20. How do I stop stacktraces truncating in logs
  21. Android exception handling best practice?
  22. What is meant by abstract=”true” in spring?
  23. In Java, is using throws Exception instead of throwing multiple specific exceptions good practice?
  24. Is there anything like .NET’s NotImplementedException in Java?
  25. JUnit: Possible to ‘expect’ a wrapped exception?
  26. Java NoSuchAlgorithmException – SunJSSE, sun.security.ssl.SSLContextImpl$DefaultSSLContext
  27. How do I write the exception from printStackTrace() into a text file in Java?
  28. Breakpoint at exception in Eclipse – how to examine Exception object?
  29. No Such Element Exception?
  30. Java – When is it a compiler error and when is it a runtime exception?

Leave a Comment