Return to Answer

##The problem##

The worst problem I see with exception handling mechanism is that it introduces code duplication in a big scale! Let's be honest: In most of projects in 95% of the time all that developers really need to do with exception is to communicate it somehow to the user (and, in some cases, to the development team as well, e.g. by sending an e-mail with the stack trace). So usually the same line/block of code is used in every place the exception is handled.

Let's assume that we do simple logging in each catch block for some type of checked exception:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ logger.error(e); } 

If it's a common exception there may be even several hundreds of such try-catch blocks in a larger codebase. Now let's assume that we need to introduce popup dialog based exception handling instead of console logging or start to additionally send an e-mail to the development team.

Wait a moment... are we really going to edit all of that several hundreds of locations in the code?! You get my point :-).

##The solution##

What we did to adress that issue was introducing the concept of exception handlers (to which I'll further refer as EH's) to centralize exception handling. To every class that needs to hande exceptions an instance of exception handler is injected by our Dependency Injection framework. So the typical pattern of exception handling now looks like this:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ exceptionHandler.handleError(e); } 

Now to customize our exception handling we only need to change the code in a single place (EH code).

Of course for more complex cases we can implement several subclasses of EHs and leverage features that our DI framework provides us. By changing our DI framework configuration we can easily switch EH implementation globally or provide specific implementations of EH to classes with special exception handling needs (for example using Guice @Named annotation).

That way we can differentiate exception handling behaviour in development and release version of application (eg. development - logging the error and halting the application, prod - logging the error with more details and letting the application continue its execution) with no effort.

##Last one thing

Last but not least, it may seem that the same kind of centralisation can be obtained by just passing our exceptions "up" until they arrive to some top level exception handling class. But that leads to cluttering of code and signatures of our methods and introduces maintenance problems mentioned by others in this thread.

The problem

The worst problem I see with exception handling mechanism is that it introduces code duplication in a big scale! Let's be honest: In most of projects in 95% of the time all that developers really need to do with exception is to communicate it somehow to the user (and, in some cases, to the development team as well, e.g. by sending an e-mail with the stack trace). So usually the same line/block of code is used in every place the exception is handled.

Let's assume that we do simple logging in each catch block for some type of checked exception:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ logger.error(e); } 

If it's a common exception there may be even several hundreds of such try-catch blocks in a larger codebase. Now let's assume that we need to introduce popup dialog based exception handling instead of console logging or start to additionally send an e-mail to the development team.

Wait a moment... are we really going to edit all of that several hundreds of locations in the code?! You get my point :-).

The solution

What we did to adress that issue was introducing the concept of exception handlers (to which I'll further refer as EH's) to centralize exception handling. To every class that needs to hande exceptions an instance of exception handler is injected by our Dependency Injection framework. So the typical pattern of exception handling now looks like this:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ exceptionHandler.handleError(e); } 

Now to customize our exception handling we only need to change the code in a single place (EH code).

Of course for more complex cases we can implement several subclasses of EHs and leverage features that our DI framework provides us. By changing our DI framework configuration we can easily switch EH implementation globally or provide specific implementations of EH to classes with special exception handling needs (for example using Guice @Named annotation).

That way we can differentiate exception handling behaviour in development and release version of application (eg. development - logging the error and halting the application, prod - logging the error with more details and letting the application continue its execution) with no effort.

Last one thing

Last but not least, it may seem that the same kind of centralisation can be obtained by just passing our exceptions "up" until they arrive to some top level exception handling class. But that leads to cluttering of code and signatures of our methods and introduces maintenance problems mentioned by others in this thread.

##The problem##

The worst problem I see with exception handling mechanism is that it introduces code duplication in a big scale! Let's be honest: In most of projects in 95% of the time all that developers really need to do with exception is to communicate it somehow to the user (and, in some cases, to the development team as well, e.g. by sending an e-mail with the stack trace). So usually the same line/block of code is used in every place the exception is handled.

Let's assume that we do simple logging in each catch block for some type of checked exception:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ logger.error(e); } 

If it's a common exception there may be even several hundreds of such try-catch blocks in a larger codebase. Now let's assume that we need to introduce popup dialog based exception handling instead of console logging or start to additionally send an e-mail to the development team.

Wait a moment... are we really going to edit all of that several hundreds of locations in the code?! You get my point :-).

##The solution##

What we did to adress that issue was introducing the concept of exception handlers (to which I'll further refer as EH's) to centralize exception handling. To every class that needs to hande exceptions an instance of exception handler is injected by our Dependency Injection framework. So the typical pattern of exception handling now looks like this:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ exceptionHandler.handleError(e); } 

Now to add e-mail sending we only need to change our code in one place (EH code).

Of course we could implement several subclasses of EHs and leverage features that our DI framework provides us. So we can switch easily EH implementation globally or provide different implementations of EH to classes with special exception handling needs (for example using Guice @Named annotation, etc.). With such a flexible framework we can for example differentiate exception handling behaviour in development and release version of application (eg. development - logging the error and halting the application, prod - logging the error with more details and letting the application continue its execution) with no effort.

##Last one thing

Last but not least, we could of course reach centralisation to some extent by just passing the exception to upper layers until they reach to some high level exception handling class. But one of reason we stopped doing it that way is that cluttering methods and methods signatures that way looks very obscure and verbose for our taste and introduce maintenance problems mentioned by others.

##The problem##

The worst problem I see with exception handling mechanism is that it introduces code duplication in a big scale! Let's be honest: In most of projects in 95% of the time all that developers really need to do with exception is to communicate it somehow to the user (and, in some cases, to the development team as well, e.g. by sending an e-mail with the stack trace). So usually the same line/block of code is used in every place the exception is handled.

Let's assume that we do simple logging in each catch block for some type of checked exception:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ logger.error(e); } 

If it's a common exception there may be even several hundreds of such try-catch blocks in a larger codebase. Now let's assume that we need to introduce popup dialog based exception handling instead of console logging or start to additionally send an e-mail to the development team.

Wait a moment... are we really going to edit all of that several hundreds of locations in the code?! You get my point :-).

##The solution##

What we did to adress that issue was introducing the concept of exception handlers (to which I'll further refer as EH's) to centralize exception handling. To every class that needs to hande exceptions an instance of exception handler is injected by our Dependency Injection framework. So the typical pattern of exception handling now looks like this:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ exceptionHandler.handleError(e); } 

Now to customize our exception handling we only need to change the code in a single place (EH code).

Of course for more complex cases we can implement several subclasses of EHs and leverage features that our DI framework provides us. By changing our DI framework configuration we can easily switch EH implementation globally or provide specific implementations of EH to classes with special exception handling needs (for example using Guice @Named annotation).

That way we can differentiate exception handling behaviour in development and release version of application (eg. development - logging the error and halting the application, prod - logging the error with more details and letting the application continue its execution) with no effort.

##Last one thing

Last but not least, it may seem that the same kind of centralisation can be obtained by just passing our exceptions "up" until they arrive to some top level exception handling class. But that leads to cluttering of code and signatures of our methods and introduces maintenance problems mentioned by others in this thread.

##The problem##

The worst problem I see with exception handling mechanism is that it introduces code duplication in a big scale! Let's be honest: In most of projects in 95% (or even more) of time all that developers really need to do with exception is to signal it somehow to user (and if possible to developers themselves by e.g. sending a mail with stack trace) and forget about it. And they do this each time the same way.

Let's assume that we do simple logging in each catch block for some type of checked exception:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ logger.error(e); } 

If it's a common exception there can be even several hundreds of such try-catch blocks in a larger codebase. Now let's assume that we need to introduce popup-based exception handling instead of console logging or add or sending mail to developers. Wait a moment... are we really going to edit all of that few hundreds of places?! You get the point.

##The solution##

What we did to adress that issue was introducing the concept of exception handlers (to which I'll further refer as EH's) to centralize exception handling. To every class that needs to hande exceptions an instance of exception handler is injected by our Dependency Injection framework. So the typical pattern of exception handling now looks like:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ exceptionHandler.handleError(e); } 

Now to add e-mail sending we only need to change our code in one place (EH code).

We can provide several methods in EH to handle different types of common exception handling situations. For example in our project one EH method displays just dialog with "Unexpected error occured" message and stack trace extracted from exception while other displays just exception message without stack trace (because it's not something developers may need to debug, just untypical behaviour from user perspective), other time we need to display "Validation error" dialog with more detail info about fields incorrectly filled by user etc.

Of course we could implement several subclasses of EHs and leverage features that our DI framework provides us. So we can switch easily EH implementation globally or provide different implementations of EH to classes with special exception handling needs (for example using Guice @Named annotation, etc.). With such a flexible (and so simple) framework built we can do such things like differentiation of exception handling behaviour in development and release version of application (eg. dev - error logging and halting application, prod - only error logging) with no effort.

##Last one thing

Last but not least, we could of course reach centralisation to some extent by just passing the exception to upper layers until they reach to some high level exception handling class. But one of reason we stopped doing it that way is that cluttering methods and methods signatures that way looks very obscure and verbose for our taste and introduce maintenance problems mentioned by others.

##The problem##

The worst problem I see with exception handling mechanism is that it introduces code duplication in a big scale! Let's be honest: In most of projects in 95% of the time all that developers really need to do with exception is to communicate it somehow to the user (and, in some cases, to the development team as well, e.g. by sending an e-mail with the stack trace). So usually the same line/block of code is used in every place the exception is handled.

Let's assume that we do simple logging in each catch block for some type of checked exception:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ logger.error(e); } 

If it's a common exception there may be even several hundreds of such try-catch blocks in a larger codebase. Now let's assume that we need to introduce popup dialog based exception handling instead of console logging or start to additionally send an e-mail to the development team. 

Wait a moment... are we really going to edit all of that several hundreds of locations in the code?! You get my point :-).

##The solution##

What we did to adress that issue was introducing the concept of exception handlers (to which I'll further refer as EH's) to centralize exception handling. To every class that needs to hande exceptions an instance of exception handler is injected by our Dependency Injection framework. So the typical pattern of exception handling now looks like this:

try{ methodDeclaringCheckedException(); }catch(CheckedException e){ exceptionHandler.handleError(e); } 

Now to add e-mail sending we only need to change our code in one place (EH code).

Of course we could implement several subclasses of EHs and leverage features that our DI framework provides us. So we can switch easily EH implementation globally or provide different implementations of EH to classes with special exception handling needs (for example using Guice @Named annotation, etc.). With such a flexible framework we can for example differentiate exception handling behaviour in development and release version of application (eg. development - logging the error and halting the application, prod - logging the error with more details and letting the application continue its execution) with no effort.

##Last one thing

Last but not least, we could of course reach centralisation to some extent by just passing the exception to upper layers until they reach to some high level exception handling class. But one of reason we stopped doing it that way is that cluttering methods and methods signatures that way looks very obscure and verbose for our taste and introduce maintenance problems mentioned by others.