On a side project I'm working on I came up with a way of handling exceptions that's adjustable by configuration. So a try/catch block might look like this:try{    fileHelper.MoveFile(file, destFolder);}catch (IOException ex){    if (exceptionHandler.HandleException(ex))    {        return ResultCode.Fail;    }    throw;}The granularity of exception handling is controlled through an enum that's set in the app.config file:public enum SystemFailureMode{    AlwaysThrow = -1,    Aggressive = 0,    Standard = 1,    Lenient = 2}This determines whether an exception is handled and returned as an error, or if it bubbles up and crashes the system. At first I thought I'd uncovered a new design pattern but now it seems like it's probably an anti-pattern. What do you guys think?After reviewing the comments and thinking about it myself, I've decided this is definitely an anti-pattern. The fact that this has the potential to turn writing unit tests into a nightmare is enough to turn me off of it.
Using configuration to determine whether to handle exception or bubble it up
design patterns;exception handling;configuration
In my opinion, the nicest way for Exception handling in C# is the same exposed in this article:http://johannesbrodwall.com/2014/02/07/c-tricks-slimming-down-your-controllers/(look for Exception handling)Please note that the same pattern can be used for Java: http://johannesbrodwall.com/2013/09/25/offensive-programming/The most important concept is: (almost)Never handle exceptions locallyThat's the simplest and the cleanest way to handle exceptions in both Java and C#. In your case you catch the exception everytime it can happen and then you configure how to handle them, am I right? Now isn't that a hint that you should centralize the exception handling elsewere? Instead of repeating the same pattern try - catch -handleExceptionInAConfigurableWay - throw every time.I personally don't see any point in configuring a global FailureMode to handle exceptions, if you have an ApplicationFilter like the one in the 1st article, and you want to change how Exception are handled, just change the behaviour of the OnException template method.Result:+1: The actual handling of exceptions should be centralized-10: Not in this way!Of course it's not possibile to throw always an Exception and handle it in a single application filter point.Sometimes you have some operations to do in case of exceptions (e.g. rollback a transaction), or in every case (e.g. an open file to close in finally block), but in any other situations, if you have to just log the exception stacktrace or pop an error message in some GUI, then just throw the exception and handle it in a single global point.Using Exceptions as a part of your business logic has never been a good pattern, and the epic failure of Java checked exception is a proof of that.