Translating Exceptions is the practice of taking one, usually checked, exception and making it into another often-unchecked exception.

An example of this is a file-writing portion of an application. It may receive an IOException while writing to its file. However, there are no recovery steps and so it translates its IOException into an ApplicationFailureError, indicating to the high-level logic that something really bad happened and that the application is now in an invalid state.

Presumably the file-writing portion also sets the IOException as the cause of the new ApplicationFailureError.

The best "Translated Exceptions" contain the stack trace of their causes.

-- Zipwow

----

Wouldn't it be better if the target exception is also checked?

And wouldn't it be simpler if the file-writing portion declares it may throw IOException? 

Isn't it obvious that file-writing portions may have problems when writing to a file that the main application needs to deal with?

Only knowing that "something really bad happened" will not tell the main application what should be done about it.

----

Low-level exceptions can be meaningless at higher levels.

For example a NullPointerException is meaningless to a DatabaseOperation. Also a ConnectionException is meaningless to a BankTransferOperation. The low level exceptions must be masked in high level exceptions when passed around, so that they always make sense in the correct abstraction.

----

See AvoidExceptionsWheneverPossible, ExceptionsAreOurFriends,  ConvertExceptions

----
CategoryException