• Power Troll (cs)

    On Error Comment

  • D Martensson (unregistered)

    I had a collegue 5-6 years ago that used the same "fix" in a conversion program, another collegue invented some very new bad words when trying to upgrade it later ;)

  • WC (unregistered)

    At some point, you've got 'new' and 'old' backwards. I suspect Trent implemented it in the old version, and the submitter implemented it in the new version.

  • GalacticCowboy (cs)

    s/Trent/Steve/

    Fixed that for ya.

  • Zolcos (cs)

    That was probably the right decision. It doesn't really fix anything, of course, but doing it the right way would just waste a lot more time. This way he can get to finishing the rewrite.

    WC:
    At some point, you've got 'new' and 'old' backwards. I suspect Trent implemented it in the old version, and the submitter implemented it in the new version.
    I get the feeling that both the new and old versions were 'old' and not part of his rewrite
  • dohpaz42 (cs) in reply to Power Troll
    Power Troll:
    On Error Resume Comment

    FTFY

  • Brogrammer (unregistered)

    Cool story, bro.

  • Roman (unregistered) in reply to dohpaz42
    dohpaz42:
    Power Troll:
    On Error Resume Comment

    FTFY

    On Troll First Post

  • Vilx- (unregistered)

    That's not the Vista Fix! That's the Universal Panacea! He has finally done it! He has found the way to make any software run error-free!

    Well, as long as that software is written in VB6 at least.

  • Bryan the K (unregistered)

    The real WTF is support for Vista? Right??

  • Mr. Cranky Language Person (unregistered)

    "Poring through the code"

    Thanks for getting that right.

  • frits (cs) in reply to Power Troll
    Power Troll:
    On Error Comment
    TRWTF is comments.
  • blah (unregistered)

    TRWTF is not performing a diff. Presumably TRRWTF is no source control.

  • DCRoss (cs)

    Problem: Software is showing error messages to user while running.

    Expected Result: User should not see error messages while running software.

    Fix: Obvious.

  • Brian (unregistered)

    Sadly, the Vista Fix requires you to dynamically generate all of your controls. Otherwise, users might still see errors when one of your controls fails to load (e.g., because the user is missing the .ocx file).

  • Nagesh (cs)

    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

  • Al Jaseera (unregistered)

    It is good thing Vista fix was implemented on DNA testing algorithm.

  • Niten (unregistered) in reply to Nagesh
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    Not all great programmers have a Computer Science degree. For that matter, not all great programmers went to college.

    And plenty of people with computer science degrees write bad code.

  • Fact Checker (unregistered) in reply to Niten
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    Not all great programmers have a Computer Science degree. For that matter, not all great programmers went to college.

    And plenty of people with computer science degrees write bad code.

    Indeed. My facts say that not one great programmer has a Computer Science degree. Also: every person with a computer science degree writes bad code.

  • Nagesh (cs) in reply to Niten
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    Not all great programmers have a Computer Science degree. For that matter, not all great programmers went to college.

    And plenty of people with computer science degrees write bad code.

    Structure thinking v/s unstructure thinking. That is pipe dream. Name 4 great programmer candidates who did not have CS degree and I will show bugs in their code.

  • Jo Poser (unregistered)

    "Poring"? Was it stinky or filmy?

    nobis... you can only spell "America" with nobis. Or something similarly stupid and confusing.

  • trtrwtf (unregistered) in reply to Fact Checker
    Fact Checker:
    Indeed. My facts say that not one great programmer has a Computer Science degree. Also: every person with a computer science degree writes bad code.

    I know a great programmer with a computer science degree. Actually, two. Three, now I come to think of it. Go check your facts.

  • fritters (unregistered) in reply to Mr. Cranky Language Person
    Mr. Cranky Language Person:
    "Poring through the code"

    Thanks for getting that right.

    No no, it's "pouring" through the code.

    As in, gasoline.

  • PedanticCurmudgeon (cs) in reply to Nagesh
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    In my day, when someone was ashamed to mention something, they didn't mention it.

    Oh, and I walked to school uphill, both ways, etc.

  • C-Octothorpe (unregistered) in reply to Nagesh
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    It's really, really sad to see how often I see supposedly "senior" or "intermediate" developers writing code like this:

    try
    {
      var returnValue = int.Parse(stringVal);
      return returnValue;
    }
    catch
    {
      // something is wrong...
      return null;
    }

    The code comment, sadly, is not mine. There was also an evil brother version of this which had an object passed in.

    try
    {
      return int.Parse((string)objectValue.ToString());
    }
    catch
    {
      return "";
    }
    

    Oh yeah, you got it! Different return values between both catches and the unhandled null ref exception, etc., etc. And lets not even mention the rewriting (badly) of existing framework code... I guess System.Int32.Parse threw too many exceptions for the developers taste.

    I've had discussions with developers who are convinced that an application should never throw an error.

  • Matthew Vines (unregistered) in reply to Nagesh
    Nagesh:
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    Not all great programmers have a Computer Science degree. For that matter, not all great programmers went to college.

    And plenty of people with computer science degrees write bad code.

    Structure thinking v/s unstructure thinking. That is pipe dream. Name 4 great programmer candidates who did not have CS degree and I will show bugs in their code.

    Name 4 programmers and I will show bugs in their code.

  • Pedantic CBE (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    I've had discussions with developers who are convinced that an application should never throw an error.
    Well, I can see where that idea is coming from.

    A GUI* application shouldn't ever die with an error unless that error is genuinely fatal and irrecoverable. In other words - out of memory or hardware fault.

    Any errors it does display should be only be caused by user error, and should never cause it to die - it should tell the user what they did wrong so they can do it right.

    So by extension any 'thrown' errors shouldn't ever get to the top layer and kill the app, and must be caught and dealt with appropriately further down the stack.

    Of course, that doesn't mean you should just catch errors for no reason.

    *Command-line on the o0ther hand should die as quickly as possible with a good error message so the user isn't sat for ages waiting for it to fail on their erroneous input.

  • Jeff (unregistered) in reply to DCRoss
    DCRoss:
    Problem: Software is showing error messages to user while running.

    Expected Result: User should not see error messages while running software.

    Fix: Obvious.

    Shoot user?
  • DaveK (cs) in reply to GalacticCowboy
    GalacticCowboy:
    s/Trent/Steve/

    Fixed that for ya.

    Same Mike/Michael and Trent as http://thedailywtf.com/Articles/Feng-Shui.aspx from the sound of it.
  • the guy behind you (unregistered) in reply to fritters
    fritters:
    Mr. Cranky Language Person:
    "Poring through the code"

    Thanks for getting that right.

    No no, it's "pouring" through the code.

    As in, gasoline.

    petrol?

  • frits (cs) in reply to Pedantic CBE
    Pedantic CBE:
    C-Octothorpe:
    I've had discussions with developers who are convinced that an application should never throw an error.
    Well, I can see where that idea is coming from.

    A GUI* application shouldn't ever die with an error unless that error is genuinely fatal and irrecoverable. In other words - out of memory or hardware fault.

    Any errors it does display should be only be caused by user error, and should never cause it to die - it should tell the user what they did wrong so they can do it right.

    So by extension any 'thrown' errors shouldn't ever get to the top layer and kill the app, and must be caught and dealt with appropriately further down the stack.

    Of course, that doesn't mean you should just catch errors for no reason.

    *Command-line on the o0ther hand should die as quickly as possible with a good error message so the user isn't sat for ages waiting for it to fail on their erroneous input.

    OK. Cool. So which pattern do you use?

    On Error Resume Next

    or

    try
    {
        //Do stuff
    }
    catch(Exception swallowAll)
    {
        //Gulp! Bellllllllllch!
    }
    
  • hoodaticus (cs) in reply to Nagesh
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    It's perfectly valid in some situations. Like adding non-unique entries to a hashtable to get the unique exemplars, for hashtables that do not have a ContainsKey method.
  • jmucchiello (cs) in reply to blah
    blah:
    TRWTF is not performing a diff. Presumably TRRWTF is no source control.
    This, and the lack of source control is almost a given.
  • C-Octothorpe (unregistered) in reply to Pedantic CBE
    Pedantic CBE:
    C-Octothorpe:
    I've had discussions with developers who are convinced that an application should never throw an error.
    Well, I can see where that idea is coming from.

    A GUI* application shouldn't ever die with an error unless that error is genuinely fatal and irrecoverable. In other words - out of memory or hardware fault.

    Any errors it does display should be only be caused by user error, and should never cause it to die - it should tell the user what they did wrong so they can do it right.

    So by extension any 'thrown' errors shouldn't ever get to the top layer and kill the app, and must be caught and dealt with appropriately further down the stack.

    Of course, that doesn't mean you should just catch errors for no reason.

    *Command-line on the o0ther hand should die as quickly as possible with a good error message so the user isn't sat for ages waiting for it to fail on their erroneous input.

    Well, the real issue is swallowing and "gracefully" catching the errors during development (I should have specified that). During development, you want the application to crash fast and crash hard. Having a little popup error message you can easily dismiss so you can get to the page you're developing, or better yet swallowing any/all error messages is just bad, bad, bad and should be punishable by death by basketball.

    I can't tell you how many times I have seen exceptions "handled" only to come and severely bite the developers in the ass during a production issue. Anytime something goes wrong during a user transaction, you need to tell them that something bad happened. Unless of course the exception was logged, corrected and that you can guarantee that the correction succeeded and nothing was lost with no side effect, in other words, as if the original transaction occured without error. Then and only then should you not notify the user, IMO.

  • Michael (unregistered) in reply to Jeff
    Jeff:
    DCRoss:
    Problem: Software is showing error messages to user while running.

    Expected Result: User should not see error messages while running software.

    Fix: Obvious.

    Shoot user?
    I see no reason to be so harsh. Just unplug their monitor.

    If they plug it back in, then you can shoot them.

  • Michael (really) (unregistered) in reply to Zolcos
    Zolcos:
    That was probably the right decision. It doesn't really fix anything, of course, but doing it the right way would just waste a lot more time. This way he can get to finishing the rewrite.
    WC:
    At some point, you've got 'new' and 'old' backwards. I suspect Trent implemented it in the old version, and the submitter implemented it in the new version.
    I get the feeling that both the new and old versions were 'old' and not part of his rewrite

    That is correct...the 'new' one was a reskinning of the old software, but with all the same code. The future rewrite was actually in Delphi.

  • C-Octothorpe (unregistered) in reply to Michael
    Michael:
    Jeff:
    DCRoss:
    Problem: Software is showing error messages to user while running.

    Expected Result: User should not see error messages while running software.

    Fix: Obvious.

    Shoot user?
    I see no reason to be so harsh. Just unplug their monitor.

    If they plug it back in, then you can shoot them.

    No. You fray the wires so that they become ground when they try to plug it in again.

  • Nagesh (unregistered) in reply to Al Jaseera
    Al Jaseera:
    It is good thing Vista fix was implemented on DNA testing algorithm.
    You have made my day!!!! May my idol still be living!?!?!?!
  • Michael (really) (unregistered) in reply to DaveK
    DaveK:
    GalacticCowboy:
    s/Trent/Steve/

    Fixed that for ya.

    Same Mike/Michael and Trent as http://thedailywtf.com/Articles/Feng-Shui.aspx from the sound of it.

    Negative...I don't recall what name I gave when submitting this story, but I don't think it was Trent (I don't even remember the original programmer's name at this point, which is surprising considering how often I silently cursed his name). I can state with authority I AM a Michael, though, and I didn't submit that story.

    And per other commenters: no, no version control. I'd have fixed that but I got into that job with almost no programming experience and 1 year of schooling 5 years prior. So my programming knowledge (including, admittedly, the mere existence of source control) was acquired entirely on the job.

    Trust me, lack of source control was the LEAST of their problems.

  • Peter (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    Michael:
    Jeff:
    Shoot user?
    I see no reason to be so harsh. Just unplug their monitor.

    If they plug it back in, then you can shoot them.

    No. You fray the wires so that they become ground when they try to plug it in again.
    "Ground" as in "ground beef"?

  • BentFranklin (unregistered)

    On Error Update Resume

  • Silfax (cs) in reply to DCRoss
    DCRoss:
    Problem: Software is showing error messages to user while running.

    Expected Result: User should not see error messages while running software.

    Fix: Obvious.

    Would that be the "two fingered eyeball poke" or routing all error messages to /dev/null ?

  • Rootbeer (cs)
    After 10 minutes of staring at the code, I just happened to glance up at the very top

    What the...? Did this happen before the invention of 'diff'?

  • drusi (unregistered) in reply to Fact Checker
    Fact Checker:
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    Not all great programmers have a Computer Science degree. For that matter, not all great programmers went to college.

    And plenty of people with computer science degrees write bad code.

    Indeed. My facts say that not one great programmer has a Computer Science degree. Also: every person with a computer science degree writes bad code.

    It's true! I have a computer science degree, and I write bad code. In my defense, I work on bad projects.

    Huh, apparently this is the second time I've had "modo" as my captcha.

  • Anon (unregistered) in reply to Nagesh

    Wasn't he living in Pakistan?

    I though Indians hated Pakistanis.

    Why would he be your idol?

  • Nagesh (cs) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    In my day, when someone was ashamed to mention something, they didn't mention it.

    Oh, and I walked to school uphill, both ways, etc.

    Lot of childs in my class walk to school with no shoes. So no big deal. I was lucky to get auto.

  • laoreet (unregistered) in reply to Fact Checker
    Fact Checker:
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    Not all great programmers have a Computer Science degree. For that matter, not all great programmers went to college.

    And plenty of people with computer science degrees write bad code.

    Indeed. My facts say that not one great programmer has a Computer Science degree. Also: every person with a computer science degree writes bad code.

    F U

  • Craig (unregistered)

    I figured that maybe The Vista Fix was that the software uninstalled Vista and installed Windows XP.

  • Jaime (cs) in reply to Nagesh
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    On Error Resume Next creates a flow where no call ever fails hard and you have to check the error code on the statement immediately after the call. This is the standard error handling model for old-fashioned C. I love it when a pattern is seen as good in C, but the same pattern is evil in VB.

    On a related note, occasionally my workstation at work gets into a state where all window creation fails. It's interesting to see how many applications don't check to see if CreateWindow returns a valid handle.

  • laoreet (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

    I remember the instructer telling me that never use "ON ERROR RESUME NEXT". I think the person who write this code did not go to class.

    It's really, really sad to see how often I see supposedly "senior" or "intermediate" developers writing code like this:

    try
    {
      var returnValue = int.Parse(stringVal);
      return returnValue;
    }
    catch
    {
      // something is wrong...
      return null;
    }

    The code comment, sadly, is not mine. There was also an evil brother version of this which had an object passed in.

    try
    {
      return int.Parse((string)objectValue.ToString());
    }
    catch
    {
      return "";
    }
    

    Oh yeah, you got it! Different return values between both catches and the unhandled null ref exception, etc., etc. And lets not even mention the rewriting (badly) of existing framework code... I guess System.Int32.Parse threw too many exceptions for the developers taste.

    I've had discussions with developers who are convinced that an application should never throw an error.

    I don't think you know what you're talking about. Try again.

Leave a comment on “The Vista Fix”

Log In or post as a guest

Replying to comment #:

« Return to Article