Lesson plan

Exception chaining

Exception chaining, or exception wrapping, is an object-oriented programming technique of handling exceptions by re-throwing a caught exception after wrapping it inside a new exception. The original exception is saved as a property (such as cause) of the new exception. The idea is that a method should throw exceptions defined at the same abstraction level as the method itself, but without discarding information from the lower levels. For example, a method to play a movie file might handle exceptions in reading the file by re-throwing them inside an exception of movie playing. The user interface doesn't need to know whether the error occurred during reading chunk of bytes or calling eof(). It needs only the exception message extracted from cause. The user interface layer will have its own set of exceptions. The one interested in cause can see its stack trace during debugging or in proper log. Throwing the right kind of exceptions is particularly enforced by checked exceptions in the Java programming language, and starting with language version 1.4 almost all exceptions support chaining. In runtime engine environments such as Java or .NET there exist tools that attach to the runtime engine and every time that an exception of interest occurs they record debugging information that existed in memory at the time the exception was thrown (stack and heap values).…

Back to article

Article summary

Exception chaining, or exception wrapping, is an object-oriented programming technique of handling exceptions by re-throwing a caught exception after wrapping it inside a new exception. The original exception is saved as a property (such as cause) of the new exception. The idea is that a method should throw exceptions defined at the same abstraction level as the method itself, but without discarding information from the lower levels. For example, a method to play a movie file might handle exceptions in reading the file by re-throwing them inside an exception of movie playing. The user interface doesn't need to know whether the error occurred during reading chunk of bytes or calling eof(). It needs only the exception message extracted from cause. The user interface layer will have its own set of exceptions. The one interested in cause can see its stack trace during debugging or in proper log. Throwing the right kind of exceptions is particularly enforced by checked exceptions in the Java programming language, and starting with language version 1.4 almost all exceptions support chaining. In runtime engine environments such as Java or .NET there exist tools that attach to the runtime engine and every time that an exception of interest occurs they record debugging information that existed in memory at the time the exception was thrown (stack and heap values).…

Key claims

No claims recorded.

Discussion questions

  1. Summarise the article in your own words. Which single claim would you verify first, and why?
  2. Which claim in this article is most likely to be revised as the sources update? How would you check its current status?
  3. If two sources disagreed about one of these facts, what would you need in order to trust one over the other?

Bibliography

No sources recorded.

Key claims and bibliography are generated from the same tracked claims and sources as the article page.