'''AntiPattern Name''':  ''ExceptionFunnel''

'''Problem''': We want to let the user know that things went wrong but not confuse him with the technical detail.

'''Context''': Exception handling.

'''Forces''': The DesignPhase deals only with the best case scenarios, so during coding exception handling are only done to make sure the code does not crash.

'''Supposed Solution''':  When a function fails just report that it failed, do not report where or why it failed.  To really make sure the maintenance programmer have lots of fun, mix this AntiPattern with very long functions.  

'''Resulting Context''':  A top level function returns an error and you have no way to find out what went wrong without debugging to the point where the exception occurs and then debugging into the aberrant function to the point where it fails etc.  

'''Design Rationale''':  Development time saved because no exception handling strategy need to be designed or implemented.

'''AntiPatternCategory''': ArchitectureAntiPattern 

'''Related''': CatchWhatYouCanHandle, EmptyCatchClause

----

'''CeePlusPlus Implementation'''

C++ makes this pattern exceptionally (;-) easy:

   catch(...) {}
So does the JavaLanguage:

  try
  {
    // something
    // in fact, lots of things
    // the more the better
  } catch(Throwable t)
  {
  }
as does PythonLanguage:
  try:
      something
  except:
      pass
and RubyLanguage:
  begin
    something
  rescue
  end
what about:
  on error resume next
...and so will most other languages that haven't heeded Meyer's advice on exceptions. That's ObjectOrientedSoftwareConstruction chapter 12, ''When the contract is broken: exception handling''.

----
'''"When a function fails just report that it failed, do not report where or why it failed."'''

A stack trace will show exactly where it failed, but I don't understand how one could show why it failed.  If we knew why it failed, couldn't we prevent it from failing?

In the exception message put in information about what the inputs were to the failing action. For example, if you were writing a parser:

   //this is just made up.
  Token t = tokens.next();
  if (IN_BRACES && t.notAllowedInBraces()) {
     // Token class has a toString() method that formats the token readably
     throw new IllegalTokenException("While IN_BRACES: illegal token: "+t);
  }

See EffectiveJava for some words on implementing a good toString() method.


----

toString(): imo not necessarily very good idea - if you use foreign libraries, you'd need to derive all classes in the foreign libs or use some way of aspect programming to decorate all foreign classes with adequate toString()s.

Our experience is that in most cases (maybe 95% of all) the stack trace and the exception type almost exactly tells you what the problem is.

Most often you don't handle any exception which you might think a situation to get it, simply because the effort is way more expensive than the increase in end user-perceived quality. You most often only handle cases in which you know for sure how to recover without telling the user anything, or situations in which you can decide from code already what's wrong, and tell the user precisely so. So imo in most cases, although we could prevent a function from failing in a specific situation, we _don't want_ to.

(flj)
----

CategoryException CategoryDevelopmentAntiPattern