• First (unregistered)

    heh.

  • steve (unregistered)

    my eyes are bleeding

  • DotNot (unregistered)

    That is just fscking ridiculous.  I can't believe someone would go to those lengths to avoid ever getting an error... ever (much less never know if their code is ever working or not).

  • (cs)

    It is just beatiful. Is this method patented, or can I use it in my own code without licensing fees? ;-)

    It is just amazing that this guy managed to keep his thinking inside the box. I imagine that each step down this evolutionary dead-end must have been initiated by the thought "there must be a better way to do this", never followed by the thought "I must be on the wrong track"...

  • Anonymous jr. (unregistered)

    I SO do not believe this is for real.
    This is made up.

  • Pyromancer (unregistered) in reply to DotNot

    fifth?

    When sinner programmers die, they are dragged to hell and forced to debug erorrless programs like that [6]

  • toxik (unregistered)

    Must've been an "Aha!" feeling when he noticed that try {} can do more then one line, and that the if statement has been around for some time...

  • (cs)

    I'm suprised he didn't rewrite the class loader.  That would be a fun one to debug in hell.  6

  • (cs)

    My groin!
    The cup, it does nothing!

    Getting quick and easy to follow feedback from where one of your programs screws up has long been a problem in programming.  If you can do away with catching errors well enough, you should be able to ensure the database just gets silently corrupted data or something, that way its the DB admin's problem, and there are no blemishes come review time for that vacant management position.

  • Devils Advocate (unregistered)

    Okay, I'm going to poke a few here, but the first sentence got me.

    "On Error Resume Next"

    As a (typically) non-VB programmer, this strikes me as:

    "I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

    Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

    Thanx
    Diablo.

  • Rain dog (unregistered) in reply to Devils Advocate

    Ok, where is this guy so we can all go beat him up.

    btw, CAPTHA is not color blind friendly.

  • scriptkiddie (unregistered) in reply to Devils Advocate

    1st post here after months of lurking...

    Anonymous:
    Okay, I'm going to poke a few here, but the first sentence got me.

    "On Error Resume Next"

    As a (typically) non-VB programmer, this strikes me as:

    "I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

    Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

    Thanx
    Diablo.


    On Error Resume Next does have its place if you are testing to see if, for instance, a certain activex object can be instantiated or not, without having your script bug out... but it is seriously misused by the masses in exactly the way you describe... and of course, use of activex might be viewed as a wtf in itself!

  • (cs)
    Alex Papadimoulis:
    Writing error-free code in Visual Basic is a cinch; just tack "On Error Resume Next" up at the top, and you're good to go.

    Thankfully, Petr Lazecky was able to step before this eclipsed to the next level of WTF and impacted a serious project. But it certainly is an interesting example of just how far one can go down the wrong path with creative invention ...

    I am reminded of a quote from Hoare.  Paraphrase: There are two ways to program: so that there are obviously no errors and so that there are no obvious errors.

    This WTF is definitely in the second category.  If I ran into this in production code, I would be rather angry.  The potential for a big mess as a result of this WTF is too likely.

    Sincerely,

    Gene Wirchenko

  • (cs)

    This just makes the Baby Jesus cry.

  • Asztal (unregistered) in reply to toxik

    Ah, but if you use try{} over more than one line, then if the first statement fails, the rest are not executed.

  • Oli (unregistered)

    I can imagine his rationale - "well it didn't fall over, so there ARE no bugs!"

  • (cs) in reply to Devils Advocate
    Anonymous:

    "On Error Resume Next"
    <clip>
    Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

    Alex was being ironic (not moronic).
  • Runtime Error (unregistered) in reply to Anonymous jr.
    Anonymous:
    I SO do not believe this is for real.
    This is made up.


    Ahh... the joyous innocence of youth.  You should really try to stay away from here Anonymous Jr.  This place isn't good for you.  Its like the cliffs note version of things that man was not meant to know and can't be unlearned.

    Most of the people that have been around for a while not only believe that its for real, we have had to fix these things.  Although I'm not really sure what would be the proper tool for fixing this one, fire I would guess.
  • Runtime Error (unregistered) in reply to mjonhanson
    mjonhanson:
    I'm suprised he didn't rewrite the class loader.  That would be a fun one to debug in hell.  6


    Thats funny, I was thinking some type of AOP wrapper would be the easiest way to implement the "Hear No Evil, See No Evil, Speak No Evil" design pattern.  But I bow to your superiour wisdom, a hacked class loaded is definetly the way to go. 
  • (cs) in reply to Devils Advocate
    Anonymous:
    Okay, I'm going to poke a few here, but the first sentence got me.

    "On Error Resume Next"

    As a (typically) non-VB programmer, this strikes me as:

    "I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

    Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

    Thanx
    Diablo.


    Sense of sarcasm anyone?  :-P
  • ChiefCrazyTalk (unregistered) in reply to Devils Advocate

    Anonymous:
    Okay, I'm going to poke a few here, but the first sentence got me.

    "On Error Resume Next"

    As a (typically) non-VB programmer, this strikes me as:

    "I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

    Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

    Thanx
    Diablo.

     

    It depends on what the "next" is in resume next.  This should be some sort of error handler, if coded correctly.

  • Randolpho (unregistered)

    What. The. Fuck.

    Seriously, I've seen some semi-sorta excusable WTFs here; fringe areas where the WTF might be OK... but this one... very highly WTF. So WTF that I can't possibly think *why* any programmer would ever want to do such a thing.

    Hmm........

     

    however.......

     

    Now that I think about it, isn't this pretty much what C programmers who ignore return codes do? [:$]

  • (cs) in reply to Asztal
    Anonymous:
    Ah, but if you use try{} over more than one line, then if the first statement fails, the rest are not executed.



    You say that like it's a bad thing.

    Wait, is my sarcasm meter dead again?
  • (cs)

    My eyes! The Google! They do nothing!

  • (cs) in reply to Devils Advocate

    Devils Advocate:
    Okay, I'm going to poke a few here, but the first sentence got me.

    "On Error Resume Next"

    As a (typically) non-VB programmer, this strikes me as:

    "I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

    Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

    Thanx
    Diablo.

    "On Error Resume Next" does have its place in the VB world, but just like anything else, in the wrong hands it can wreak havoc.

    Your interpretation of the statement is fairly accurate. However you can test at any point in your code to see if an error occurred, and account for it (this is how you tell good programmers from hobbyists). These errors don't necessarily result from poorly written code, there are plenty of valid reasons: database server went down as the program was running, query timeout was exceeded, no read permission on remote files, etc etc. This is stuff you can't always test for or anticipate.

    One alternative is "On Error Goto", which is just frickin scary and amateurish to use. I want to handle my errors, not jump to a certain line in my code whenever something goes wrong. I suppose you could just omit error-handling completely and let the program crash when you encounter such a problem. I wouldn't recommend it.

  • (cs)

    I have to commend Dave on his ingenuity, but he's clearly ignorant of the true essence of programming. The true way is to never bother with try{}blocks at all. If your code compiles, then, by definition, it's error free. If it crashes, it's someone else's fault. I usually blame Microsoft and say nothing can be done about it.

    --Rank

    Do. Or do not. There is no try{}.  --Yoda

     

  • (cs) in reply to ChiefCrazyTalk

    No, in VB next means next... in this case, handle errors by going to the next statement and continuing!

    Of course I whole-heartedly agree abuot what the error handler SHOULD do, but VB's "on error resume next" doesn't do any of that

  • (cs)

    This one is more nightmarish than funny.  Someone like this discovering generics is like a baby finding a loaded handgun.

  • (cs)

    Wow Oh Wow.  My EYES are on fire![:S]

  • (cs) in reply to mjonhanson
    mjonhanson:
    I'm suprised he didn't rewrite the class loader.  That would be a fun one to debug in hell.  6

    Wouldn't it be easier to just wrap every single called method, then import the wrappers instead of the real libraries? More complex probably, but cut-n-paste easier. Just catch everything and return false. Plus it works seamlessly with normal code libraries, so you can replace coworkers' code with throw-free versions! You just have to install the wrapper library.

    Well, I guess that goes for the classloader too.
  • Wayne (unregistered)

    I love it.  A WTF with generic delegates.  This is a bleeding-edge WTF.

  • (cs) in reply to jmeyer43
    jmeyer43:
    No, in VB next means next... in this case, handle errors by going to the next statement and continuing!

    Of course I whole-heartedly agree abuot what the error handler SHOULD do, but VB's "on error resume next" doesn't do any of that


    You can interrogate the error status at any point, but it is too easy to miss a point.  If you do not anticipate a particular statement throwing an error, then you will never see one.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to jmeyer43
    jmeyer43:

    No, in VB next means next... in this case, handle errors by going to the next statement and continuing!

    Of course I whole-heartedly agree abuot what the error handler SHOULD do, but VB's "on error resume next" doesn't do any of that

    What would you rather have it do? Is there another language that automatically does something (other than crash the program) whenever an error is generated? If so, please tell me so I can begin using it immediately.

    On Error Resume Next is basically like putting every statement in a try block with an empty catch after it. It's up to the programmer to fill in the catch block. Don't blame the language when people produce stupid code. As you can see with today's WTF, it's just as probable in a non-VB environment.

  • Phil (unregistered)

    I've never seen such a nitpicky, jealous group before.

    Your code is only this error-free in your dreams.

  • (cs) in reply to Rank Amateur

    Rank Amateur:

    Do. Or do not. There is no try{}.  --Yoda

    Now *that's* funny!

  • maht (unregistered) in reply to Manni
    Manni:

    On Error Goto", which is just frickin scary and amateurish to use.



    not necessarily, it is just the same as resume next but the lines are shuffled about so that it just pops the error handling code away from the eyes, exceptions should be exceptional



    Exit Sub

    errorsgotohere:

    ' clean up or back out
    resume

    End Sub


    btw. the CAPTCHA is typing blind


  • (cs) in reply to Runtime Error
    Anonymous:
    [...Although I'm not really sure what would be the proper tool for fixing this one, fire I would guess.

    <font size="5">F</font>iring would be a better solution.
  • (cs) in reply to Sean
    Sean:
    This one is more nightmarish than funny.  Someone like this discovering generics is like a baby finding a loaded handgun.
    <font size="5">H</font>ence the expression, "A little knowledge is a dangerous thing." --Alexander Pope
  • (cs) in reply to jmeyer43

    Well. It's been some time since I last saw a true WTF like this one. I mean, you have to try hard not to shout "WhatTheF...!" or burst in a histerical laughter at the sight of this. Truly enjoyable. For those of us who don't have to cope it, that is.

  • (cs) in reply to ChiefCrazyTalk
    Anonymous:

    Anonymous:
    Okay, I'm going to poke a few here, but the first sentence got me.

    "On Error Resume Next"

    As a (typically) non-VB programmer, this strikes me as:

    "I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

    Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

    Thanx
    Diablo.

     

    It depends on what the "next" is in resume next.  This should be some sort of error handler, if coded correctly.

     

    And this case, "correctly" probably means using "on error goto", not "on error resume next".

     

    This post not [pi]-approved.

  • (cs) in reply to jmeyer43
    jmeyer43:

    No, in VB next means next... in this case, handle errors by going to the next statement and continuing!

    Of course I whole-heartedly agree abuot what the error handler SHOULD do, but VB's "on error resume next" doesn't do any of that

    No, but you have to do it. ON ERROR RESUME NEXT is the way to tell the compiler explicitly that you are handling your errors in place, and don't want to mess with explicit handlers or worse, get the program to crash without explanation. Use it, and it will make your life easy. Abuse it, and hell ensues.

  • dasmb (unregistered)

    The real amazing thing here is that the .NET "solution" is technically pretty complex and requires advanced knowledge of delegation.

    Meaning that what we have is not the "Brillant" programmer who has no talent, but a rather smart guy who just doesn't get it.

    But then, in our industry more horrors have been created out of cleverness than out of stupidity.  Just ask any Notes developer (provided he isn't doped up on morphine...i understand that's the only way some of them make it through the day).

  • (cs) in reply to bit
    bit:
    jmeyer43:

    No, in VB next means next... in this case, handle errors by going to the next statement and continuing!

    Of course I whole-heartedly agree abuot what the error handler SHOULD do, but VB's "on error resume next" doesn't do any of that

    No, but you have to do it. ON ERROR RESUME NEXT is the way to tell the compiler explicitly that you are handling your errors in place, and don't want to mess with explicit handlers or worse, get the program to crash without explanation. Use it, and it will make your life easy. Abuse it, and hell ensues.

    Just to clarify: it's wonderful to have proper error handling methods. By using ON ERROR RESUME NEXT you're explicitly opting for an "old school" style of programming, in which you refuse to use those methods and manually anticipate your error scenarios. As Gene pointed out, this is not the best thing to do. But, anyway, even when using the fanciest error handling system, you have to cope with the errors in the code of your handler, so you are already anticipating error conditions, right?

  • (cs) in reply to Manni
    Manni:

    One alternative is "On Error Goto", which is just frickin scary and amateurish to use. I want to handle my errors, not jump to a certain line in my code whenever something goes wrong. I suppose you could just omit error-handling completely and let the program crash when you encounter such a problem. I wouldn't recommend it.

    Actually it is called an exception handler and it is how professionals handle exceptions in their code. This allows you to have a generic exception handler to handle the exceptions.  

    IF you don't do this, your program will crash. Letting your program crash is pretty scary and amatuerish. I would want to handle my errors, and not just crash whenever something goes wrong.

    I guess I don't understand how you plan on handling your errors WITHOUT using on error goto?

  • McTesty (unregistered) in reply to chrismcb

    Aw man, it would have been so easy to add error logging to his delegate and made this entire WTF go away!

  • (cs) in reply to bit
    bit:
    ON ERROR RESUME NEXT is the way to tell the compiler explicitly that you are handling your errors in place, and don't want to mess with explicit handlers or worse, get the program to crash without explanation. Use it, and it will make your life easy. Abuse it, and hell ensues.


    A few years back I had the misfortune of trying to develop a basic MUD client in VB.  This heinous construction was actually amazingly useful, because I was writing an end-user program.  My errors were always things that if it didn't work, the user would notice and try again, so it was far preferable to ignore the errors than to have the program crash every time they did something that wasn't quite right or the server wouldn't take the connection.

    Thankfully, I've long since learned how to use proper error handling.  Even when you don't care about an error, you should at least have the decency to catch only that particular error, so that other problems surface when you need them to.

    -FM
  • (cs) in reply to chrismcb
    chrismcb:
    Actually it is called an exception handler and it is how professionals handle exceptions in their code. This allows you to have a generic exception handler to handle the exceptions. 

    IF you don't do this, your program will crash. Letting your program crash is pretty scary and amatuerish. I would want to handle my errors, and not just crash whenever something goes wrong.

    I guess I don't understand how you plan on handling your errors WITHOUT using on error goto?

    The better solution is to have the error handling alongside the code that triggers that error (with, say, a try-catch block).  It makes it easier to figure out which error is being handled by what code, and if you happen to have a bunch that all need the same fix, you dump it in a function and call the function.  I'm thankfully not up to date on VB, so I can't tell you if such a construction even exists, but it's definitely the Right Way to handle errors (unless used as above).

    -FM
  • RB (unregistered) in reply to Rank Amateur

    Do. Or do not. There is no try{}.  --Yoda

     

    yeah but there's a catch{} to everything

     

  • Runtime Error (unregistered) in reply to FunnyMan

    Whie the Java version is nice, there is still to much code hardcoded in the, uh, code.  What he needs to do is to move all those function names and arguments to an XML file and write a class to parse that and execute it through reflection, all the while discarding all those pesky exceptions.

  • tim (unregistered) in reply to steve
    Anonymous:
    my eyes are bleeding

    I'm right there with you.

Leave a comment on “The Perils of Error-free Code”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article