Tech Off Thread

3 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Error Handling Routines

Back to Forum: Tech Off
  • User profile image
    billh

    At what point is the creation of code is the "right time" to implement error handling routines?  Typically in the past they are usually one of the last pieces I put into place in whatever I am working on, only because I'd rather see how the code works (or doesn't) and investigate all reasonable avenues of potential abuse/misuse first.  I'd rather be aware of all the ways that something could break, whether the break is intentional or not, before putting in the error handlers (within reason of course).  I'm wondering if that is just a personal workstyle preference, or if there are better ways of going about it.  And no, I don't work on anything of critical importance like software for airlines or power plants.

  • User profile image
    sundararajan

    Its always better to avoid throwing exceptions, that is write error handling code. because as far as i know in .Net raising exceptions is a bit of performance sensitive operation.

    you r right. u should write error handling code. u should know where/when/why ur code will break and what/how/where to handle it safely.

    its not about writing code to mission critical applications but its about the cleaner way and a reliable way of programming.

    regards,
    sundararajan.s

  • User profile image
    blowdart

    For me it would depend on what the expected "errors" are.

    Too many people make what are normal conditions errors, for example a lookup on a surname which fails is not an error condition, nor should it be treated as such.

    There's also considerations about how to notify error conditions, a return value, a status property or an exception. Exceptions are very heavy to throw and yet some people use them for every little condition. They should, in my opinion, be used for the truely exceptional circumstances, the "I had a hard drive there a minute ago, where's it gone?" type errors.

    Assuming you agree that errors are truely extraordinary conditions you cannot normally code for then I admit I like to work out what exceptions could be thrown as soon as possible for two reasons;

    1) I can then document them in the function header (and thus in the generated ndoc chm)

    2) I can catch on very specific conditions as soon as possible and react appropriatly. Of course there will be things you can't react to and thus must simply tell the user what has gone wrong and that code I leave till last because it's boiler plate and it's easier to debug if you get a raw exception which kicks off the JIT debugger Smiley

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.