dcsimg
Page 2 of 2 FirstFirst 12
Results 41 to 46 of 46

Thread: [Discussion] When NOT to use Structured Exception Handling

  1. #41
    PowerPoster SJWhiteley's Avatar
    Join Date
    Feb 2009
    Location
    South of the Mason-Dixon Line
    Posts
    2,256

    Re: [Discussion] When NOT to use Structured Exception Handling

    I don't think it's Microsoft, specifically, saying 'thou must use structured exception handling!'.

    Structured exception handling has been a tried and true method of handling errors before Microsoft was born; it may not have looked like it, but it was.

    The issue is the VB never had it - then it did. I can telly you, I was a tough convert to it, but now I have seen the benefits. But, that isn't the mantra...the new mantra is that: 'thy program shall never cause an error!'

    I stick by this - If your program causes an exception handler to fire, you have done something wrong (true, there area few areas where you have little choice to use an exception handler - file handling is an example).

    There is a prevalence in the programming world to allow exceptions to 'bubble up' to the caller; I believe this promotes laziness and results in pretty crappy programs with obnoxious dialog boxes. It's a viable technique in a very few circumstances. However, if you are only performing mathematical calculations there is absolutely zero reason an error should occur. Zero. None.

    But I, like 100.0% of all other people who program, are lazy. If you think you aren't then I hope someone else is scrutinizing ones code. Because I know I'm lazy, and I make mistakes, I have a global exception handler (and, hopefully, a handler for every thread I create). If that handler ever fires, it means I messed up.

    Additionally, and exception handler should be used at the absolute smallest level of granularity - it's actually very lazy to just wrap a whole file writing routine in an exception handler. The larger the error handler span, the potentially larger the 'types' of errors that could occur, and the more difficult it is to generate a meaningful error message - thus most programmers don't. We end up with 'object or with variable not set' error message boxes. Arrgh!

    Basically, an Unstructured exception handler does the exact opposite of what's required: wrappers large chunks of code (out of necessity, since it's actually more difficult to create fine granularity unstructured error handling); pretty much ignores most errors; allows for sloppy coding because the error handler catches and often continues, hiding the poor coding (You don't use mahogany for your cabinets if you are going to put a pine laminate on top).
    "Ok, my response to that is pending a Google search" - Bucky Katt.
    "There are two types of people in the world: Those who can extrapolate from incomplete data sets." - Unk.
    "Before you can 'think outside the box' you need to understand where the box is."

  2. #42
    I'm about to be a PowerPoster! kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: [Discussion] When NOT to use Structured Exception Handling

    The other thing about bubbling up exceptions is the farther an exception gets sent up the stack, the more chance that the app will not be in a recoverable state, and will need to be restarted.

    When you handle errors as they happen properly, you can easily recover the app and the user can continue to go about using it.

    If you ignore errors with things like resume next, then the app is likely in an unknown state at that point, and when the user continues to work in it, there is much more chance of it breaking down, because objects are in a miscellaneous state of being alive or destroyed or whatever, because half way through a cleanup routine that had on error resume next, it bombed out.

  3. #43
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    34,902

    Re: [Discussion] When NOT to use Structured Exception Handling

    I would say that Resume Next is entirely possible, but I have serious doubts as to whether Resume is EVER safe. At least, I don't believe the compiler can be written to determine whether Resume even makes sense in the current context.
    My usual boring signature: Nothing

  4. #44

    Re: [Discussion] When NOT to use Structured Exception Handling

    I suppose the whole matter is preference. You can choose to have good code that shouldn't error, or you can code sloppily, and rely on error catchers to solve your problems.

    IMHO, I use error catchers in the alpha/beta stages of a program, but by the time I get that program completed, I have a full blown error system that handles any errors that might occur in the program. It's just a matter of taking the time to actually coding it, and it logically helping the program and making sense.

    Resume Next is a habit I haven't even looked into, hearing so much can go wrong with using Resume Next, so I missed that boat, and don't plan on joining it.

  5. #45

    Thread Starter
    VB Addict Pradeep1210's Avatar
    Join Date
    Apr 2004
    Location
    Inside the CPU...
    Posts
    6,614

    Re: [Discussion] When NOT to use Structured Exception Handling

    Though all these suggestions are undoubtedly good, I think we are deviating from the base topic this thread was started in the first place. We were discussing situations where UEH works better than SEH. So we assume we are in a situation where an error will necessarily occur, and we have to choose whether to use SEH or UEH.

    @Shaggy: Whether a programming construct is safe or not depends entirely on the programmer coding it and the situation. (what do you think about Do..Loop without condition?) The language should provide the flexibility to the programmer to do whatever he wants to do and leave the rest unto him. If he wants to execute the same line again, the language should provide him some way to execute the same line again. Same thing with Resume Next.
    Pradeep, Microsoft MVP (Visual Basic)
    Please appreciate posts that have helped you by clicking icon on the left of the post.
    "A problem well stated is a problem half solved." — Charles F. Kettering

    Read articles on My Blog101 LINQ SamplesJSON ValidatorXML Schema Validator"How Do I" videos on MSDNVB.NET and C# ComparisonGood Coding PracticesVBForums Reputation SaverString EnumSuper Simple Tetris Game


    (2010-2013)
    NB: I do not answer coding questions via PM. If you want my help, then make a post and PM me it's link. If I can help, trust me I will...

  6. #46
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    104,705

    Re: [Discussion] When NOT to use Structured Exception Handling

    Quote Originally Posted by Pradeep1210 View Post
    Whether a programming construct is safe or not depends entirely on the programmer coding it and the situation. (what do you think about Do..Loop without condition?) The language should provide the flexibility to the programmer to do whatever he wants to do and leave the rest unto him. If he wants to execute the same line again, the language should provide him some way to execute the same line again. Same thing with Resume Next.
    First up, the language does do that. On Error Resume Next is part of the VB language and you can use it if you want to. If you take pride in the code you write though, you'll choose not to. Remember, UEH is a VB thing. SEH is the only option in C++, Java, C# and I'm not sure what other languages and I don't hear any developers from those camps bemoaning the lack of a construct like On Error Resume Next.

    Secondly, there seem to be a lot of people posting to this thread who have never had an issue handling any of their real-world exceptions and maintaining the flow they desire using SEH. You seem to be the only one insisting that there are situations where UEH would be better yet you have yet to provide a realistic example. If you're the one insisting that there are situations where UEH would be better yet you can't even come up with a real-world example then the only conclusion I can draw is that either such situations don't exist or that they are so uncommon as to be insignificant. I have never coded in VB6 so I didn't get used to using On Error at all. I've never used it in VB.NET and I've never met a situation where I thought it could offer me something that a Try...Catch block couldn't.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width