DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 8 of 8

Thread: Error Handling

Hybrid View

  1. #1
    Steve Guest

    Error Handling

    Sorry if this is not the best place to post this - can anyone recommend a
    different group where this would be more appropriate if it isn't ?

    I've been having an interesting discussion with a colleague about error
    handling in the VB.Net product we are developing - here's a snippet of his
    view :

    'Why do normal sql statements need error handling? As long as the code is
    bug free and the upgrade done properly, the sql statements will always work
    against the config db.'

    Is this a sensible argument ? He goes on to argue that 'exception handling
    is pretty expensive' - I'm not sure about that, when an error occurs an
    exception is going to het thrown by the OS (if not at a higher level) and we
    need to catch it. Once it's happened I don't see how 'expensive' comes into
    it - it doesn't get more expensive than an error !

    What do others think ? Is there merit in his arguement that I am missing ?

    Thanks for your comments.

    Steve







  2. #2
    Patrick Toughton Guest

    Re: Error Handling


    Hi Steve,

    "Steve" <spw@totalise.co.uk> wrote:
    >'Why do normal sql statements need error handling? As long as the code is
    >bug free and the upgrade done properly, the sql statements will always work
    >against the config db.'
    >
    >Is this a sensible argument ?


    No. If you could write bug-free SQL statements, then you should be able to
    write bug-free VB.NET, C#, C++, Java, etc... If everyone could write 100%
    bug-free code, there would be no such thing as error handling in the first
    place.

    >He goes on to argue that 'exception handling
    >is pretty expensive' - I'm not sure about that, when an error occurs an
    >exception is going to het thrown by the OS (if not at a higher level) and

    we
    >need to catch it. Once it's happened I don't see how 'expensive' comes

    into
    >it - it doesn't get more expensive than an error !


    There's an element of truth in his point, but overall it appears as if he's
    misunderstood the performance penalty. The real penalty lies in throwing
    the error, not in the error handling itself. Check out this following article
    from MS. In particular, note the last paragraph...

    <quote>
    Traditional Visual Basic error handling uses the On Error GoTo and On Error
    Resume Next statements. These are not always easy to design, and the resulting
    source code is often convoluted and difficult to read and maintain.

    Visual Basic .NET offers structured exception handling with the Try ... Catch
    ... Finally statements. This is based on a control structure that is flexible
    and easy to read. Structured exception handling can check a given block of
    code for several different exceptions and handle each one differently.

    Both approaches carry some performance overhead. Using the On Error Resume
    Next statement obliges the compiler to generate additional intermediate language
    (IL) for every source statement in the block following the On Error Resume
    Next statement. A Catch block changes the state of the Err object on entry
    and on exit. Preliminary testing indicates that the performance is roughly
    equivalent for both approaches when the block has fewer than 20 source statements.
    However, blocks of several hundred statements should perform better with
    Try and Catch, because On Error Resume Next generates more IL for otherwise
    identical source code.

    If you do not have a compelling reason to use On Error statements, you should
    use structured exception handling. For more information, see Structured Exception
    Handling.

    Throwing Exceptions
    Although structured exception handling is useful, you should use it exclusively
    for exceptions. An exception is not necessarily an error, but it should be
    something that happens infrequently and is not expected in normal operation.
    Throwing exceptions takes more processing time than testing and branching,
    for example using a Select construction or a While loop. Exceptions also
    make your code harder to read when used for normal flow control. You should
    not use them as a way of branching or returning values.

    Catching Exceptions
    Try ... Catch ... Finally constructions incur very little performance overhead
    unless an exception is thrown. In other words, creating an exception handler
    does not degrade performance, and you should not hesitate to use structured
    exception handling when you expect the exception to happen rarely.
    </quote>

    http://www.msdn.microsoft.com/librar...tchperfopt.asp

    /Pat
    --------------------------
    It's the platform, stupid.
    --------------------------



  3. #3
    Michael Bennett Guest

    Re: Error Handling

    In article <3e4a9089@tnews.web.devx.com>, spw@totalise.co.uk says...
    >
    > 'Why do normal sql statements need error handling? As long as the code is
    > bug free and the upgrade done properly, the sql statements will always work
    > against the config db.'
    >
    > Is this a sensible argument ?
    >
    > Steve
    >

    You are trapping connection errors, yes?

    Since most of this has happened around here at one time or another, how
    about:

    What if the DB drops out between connection and sql statement
    completion?

    What if DB gets corrupted?

    If the DB is on the client machine what if it gets moved, deleted, or
    over-written?

    Michael

  4. #4
    Steve Guest

    Re: Error Handling

    I think we should be trapping all errors - my colleagues view is that if
    there's an error like the db corrupt or server down, the whole app is going
    to fall over so it will be obvious there is abig problem. I can't see any
    logic in not catching errors and saying to the user that 'the database
    server is down' rather than 'unhandled exception' - if nothing else it means
    most users will appreciate it's not the a bug in the app whereas 'unhandled
    exception' will probably have them thinking it's the software's fault.

    He is quite adament so I just kind of wondered if he has a point - as yet no
    one has agreed with him other than saying that error handling is 'more
    expensive' than not having it which maybe true for cpu clicks but probably
    not for the pounds/dollars/euros ....

    "Michael Bennett" <mikey0131@mac.com> wrote in message
    news:MPG.18b47b7dfdb95c5a9896ba@news.devx.com...
    > In article <3e4a9089@tnews.web.devx.com>, spw@totalise.co.uk says...
    > >
    > > 'Why do normal sql statements need error handling? As long as the code

    is
    > > bug free and the upgrade done properly, the sql statements will always

    work
    > > against the config db.'
    > >
    > > Is this a sensible argument ?
    > >
    > > Steve
    > >

    > You are trapping connection errors, yes?
    >
    > Since most of this has happened around here at one time or another, how
    > about:
    >
    > What if the DB drops out between connection and sql statement
    > completion?
    >
    > What if DB gets corrupted?
    >
    > If the DB is on the client machine what if it gets moved, deleted, or
    > over-written?
    >
    > Michael




  5. #5
    Kent Guest

    Re: Error Handling


    Steve,

    Sounds as though your colleagues are being lazy. Trapping these errors is
    always better than just letting the app fail. I would think that after a
    few crashes, they'll suddenly become as enlightened as you are.

    Kent

    "Steve" <spw@totalise.co.uk> wrote:
    >I think we should be trapping all errors - my colleagues view is that if
    >there's an error like the db corrupt or server down, the whole app is going
    >to fall over so it will be obvious there is abig problem. I can't see any
    >logic in not catching errors and saying to the user that 'the database
    >server is down' rather than 'unhandled exception' - if nothing else it means
    >most users will appreciate it's not the a bug in the app whereas 'unhandled
    >exception' will probably have them thinking it's the software's fault.
    >
    >He is quite adament so I just kind of wondered if he has a point - as yet

    no
    >one has agreed with him other than saying that error handling is 'more
    >expensive' than not having it which maybe true for cpu clicks but probably
    >not for the pounds/dollars/euros ....
    >
    >"Michael Bennett" <mikey0131@mac.com> wrote in message
    >news:MPG.18b47b7dfdb95c5a9896ba@news.devx.com...
    >> In article <3e4a9089@tnews.web.devx.com>, spw@totalise.co.uk says...
    >> >
    >> > 'Why do normal sql statements need error handling? As long as the code

    >is
    >> > bug free and the upgrade done properly, the sql statements will always

    >work
    >> > against the config db.'
    >> >
    >> > Is this a sensible argument ?
    >> >
    >> > Steve
    >> >

    >> You are trapping connection errors, yes?
    >>
    >> Since most of this has happened around here at one time or another, how
    >> about:
    >>
    >> What if the DB drops out between connection and sql statement
    >> completion?
    >>
    >> What if DB gets corrupted?
    >>
    >> If the DB is on the client machine what if it gets moved, deleted, or
    >> over-written?
    >>
    >> Michael

    >
    >


  6. #6
    blob Guest

    Re: Error Handling


    "Steve" <spw@totalise.co.uk> wrote:
    >I think we should be trapping all errors - my colleagues view is that if
    >there's an error like the db corrupt or server down, the whole app is going
    >to fall over so it will be obvious there is abig problem. I can't see any
    >logic in not catching errors and saying to the user that 'the database
    >server is down' rather than 'unhandled exception' - if nothing else it means
    >most users will appreciate it's not the a bug in the app whereas 'unhandled
    >exception' will probably have them thinking it's the software's fault.
    >
    >He is quite adament so I just kind of wondered if he has a point - as yet

    no
    >one has agreed with him other than saying that error handling is 'more
    >expensive' than not having it which maybe true for cpu clicks but probably
    >not for the pounds/dollars/euros ....
    >
    >"Michael Bennett" <mikey0131@mac.com> wrote in message
    >news:MPG.18b47b7dfdb95c5a9896ba@news.devx.com...
    >> In article <3e4a9089@tnews.web.devx.com>, spw@totalise.co.uk says...
    >> >
    >> > 'Why do normal sql statements need error handling? As long as the code

    >is
    >> > bug free and the upgrade done properly, the sql statements will always

    >work
    >> > against the config db.'
    >> >
    >> > Is this a sensible argument ?
    >> >
    >> > Steve
    >> >

    >> You are trapping connection errors, yes?
    >>
    >> Since most of this has happened around here at one time or another, how
    >> about:
    >>
    >> What if the DB drops out between connection and sql statement
    >> completion?
    >>
    >> What if DB gets corrupted?
    >>
    >> If the DB is on the client machine what if it gets moved, deleted, or
    >> over-written?
    >>
    >> Michael

    >
    >


    I'll be blunt. Tell the idiot to shut his trap. How are you going to know
    what actually caused a problem? If the DB is corrupt and a call to a stored
    proc(for example) fails due that reason, how will you know? You can log
    the info but without catching exceptions that are thrown you will never know
    what caused the problem other than a line of code. As for expensiveness
    in respect to exception handling, be smart. I learned a few things about
    exception handling in reading the new Don Box book. IE castclass vs. isinst.
    Very, very insightful. Also, be aware of the expense of exceptions when
    they are caught and rethrown and caught and rethrown etc. This is a problem
    that I have just ran into with some (sorry to say it) VB.NET modules that
    have been written for us. The very last call to the database catches an
    exception, rethrows, it is caught again, rethrown, caught again, rethrown,
    etc.


  7. #7
    Dave Guest

    Re: Error Handling


    "Steve" <spw@totalise.co.uk> wrote:
    >Sorry if this is not the best place to post this - can anyone recommend

    a
    >different group where this would be more appropriate if it isn't ?
    >
    >I've been having an interesting discussion with a colleague about error
    >handling in the VB.Net product we are developing - here's a snippet of his
    >view :
    >
    >'Why do normal sql statements need error handling? As long as the code is
    >bug free and the upgrade done properly, the sql statements will always work
    >against the config db.'
    >
    >Is this a sensible argument ? He goes on to argue that 'exception handling
    >is pretty expensive' - I'm not sure about that, when an error occurs an
    >exception is going to het thrown by the OS (if not at a higher level) and

    we
    >need to catch it. Once it's happened I don't see how 'expensive' comes

    into
    >it - it doesn't get more expensive than an error !
    >
    >What do others think ? Is there merit in his arguement that I am missing

    ?
    >
    >Thanks for your comments.
    >
    >Steve
    >
    >

    It's pretty stupid to just pretend that exceptions won't happen. There's
    a wide continuum of how far you can go with this, but my philosophy is to
    explicitly check for what I can reasonably expect to possibly go wrong and
    then take appropriate action (e.g., check for existence of a file in the
    expected location, etc.) and for anything else I just ensure that I have
    a way of getting the exception call stack back to the developers, so they
    don't have to wonder where the error occurred. Even if you take my approach,
    you still have to catch the unexpected exceptions in order to at least grab
    the call stack and possibly display a human-readable message.

    What you certainly don't want to do is have a lot of logic redirection based
    on exceptions that are thrown. This is how to write spaghetti code.





  8. #8
    Mark Bax Guest

    Re: Error Handling

    Steve,

    Take a look at the help topic titled "Application.OnThreadException Method",
    then breath a sigh of relief, because you can eat your cake and have it too
    :-)

    (See my post above "Global" Error Handler in VB .NET)

    Mark

    "Steve" <spw@totalise.co.uk> wrote in message
    news:3e4a9089@tnews.web.devx.com...
    > Sorry if this is not the best place to post this - can anyone recommend a
    > different group where this would be more appropriate if it isn't ?
    >
    > I've been having an interesting discussion with a colleague about error
    > handling in the VB.Net product we are developing - here's a snippet of his
    > view :
    >
    > 'Why do normal sql statements need error handling? As long as the code is
    > bug free and the upgrade done properly, the sql statements will always

    work
    > against the config db.'
    >
    > Is this a sensible argument ? He goes on to argue that 'exception

    handling
    > is pretty expensive' - I'm not sure about that, when an error occurs an
    > exception is going to het thrown by the OS (if not at a higher level) and

    we
    > need to catch it. Once it's happened I don't see how 'expensive' comes

    into
    > it - it doesn't get more expensive than an error !
    >
    > What do others think ? Is there merit in his arguement that I am missing

    ?
    >
    > Thanks for your comments.
    >
    > Steve
    >
    >
    >
    >
    >
    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center