Error handling patterns



  • An open space, a few programmers, everyone doing his stuff, silently typing, no one talking.
    From time to time, one of the typists bursts into an incredible laugh.

    It is not because he is surfing funny web sites.

    There is so much fun in our codebase that no one needs to go far away in search of a good laugh.

    We all know he just found some new obsucre funny piece of code in our wonderful code base and gather at his desk to have a little laugh with him:



    public void Load() {

    Cursor c = Cursor.Current;

    try {

    Cursor.Current = Cursors.WaitCursor;

    _load();

    }

    catch (EnterpriseException xex) {

    this._log.WriteLine(Category.Error, eex.ToString());

    }

    catch (ProgramException piex) {

    this._log.WriteLine(Category.Error, pex.ToString());

    }

    catch (Exception ex) {

    this._log.WriteLine(Category.Error, ex.ToString());

    }

    finally {

    Cursor.Current = c;

    }

    }




    Then everything comes back to normal, and in a few seconds, the same guy bursts into an incredible laugh again.

    He just scrolled to method just above the famous Load:




    public void Save() {

    Cursor c = Cursor.Current;

    try {

    Cursor.Current = Cursors.WaitCursor;

    _save();

    }

    catch (EnterpriseException xex) {

    this._log.WriteLine(Category.Error, eex.ToString());

    }

    catch (ProgramException piex) {

    this._log.WriteLine(Category.Error, pex.ToString());

    }

    catch (Exception ex) {

    this._log.WriteLine(Category.Error, ex.ToString());

    }

    finally {

    Cursor.Current = c;

    }

    }




    And in no more than 30 seconds later, no one is surprised to find the method just above the first one:




    public void Add(object[] items) {

    Cursor c = Cursor.Current;

    try {

    Cursor.Current = Cursors.WaitCursor;

    _add(items);

    }

    catch (EnterpriseException xex) {

    this._log.WriteLine(Category.Error, eex.ToString());

    }

    catch (ProgramException piex) {

    this._log.WriteLine(Category.Error, pex.ToString());

    }

    catch (Exception ex) {

    this._log.WriteLine(Category.Error, ex.ToString());

    }

    finally {

    Cursor.Current = c;

    }

    }





    And this is not some amateurs' job. The guys who wrote this code are very serious about catching all their exceptions.



  • I used to call that Polydorkism, in that the perpetrator is apparently unaware of the usefulness of Polymorphism, and is thus a dork. I remember catching a team lead doing this once. He was not a bad programmer overall, but he suffered from the same more-is-better attitude toward source code that underlies products like Vista, Multics, or Office 2007. I think his response to my critique was something like "well, at least this way anyone needing subclass-specific logic willl have a hook to hang it on," as if he was doing us some kind of favor by going ahead and typing in all the possible subclass names...

    The fact that these particular coders are "very serious about catching all their exceptions" is revealing, I think. I typically don't agree with people who say things like that. Overall, many applications really need far less exception handling code than they actually contain, and I get the impression sometimes that the mental lines between "debugging" and "error handling" are blurred for people who write code like this. This is one of the many forms of architectural tunnel-vision that I run into (other examples are obsession with logging, obsession with configurability, etc.)  </offtopicflamebait>


Log in to reply