Comment On The Perils of Error-free Code

heh.

my eyes are bleeding

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).

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"...

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

fifth?

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

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...

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

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.

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.

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

btw, CAPTHA is not color blind friendly.

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!

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

This just makes the Baby Jesus cry.

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

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

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).

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.

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. 

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

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.

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? [:$]

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?

My eyes! The Google! They do nothing!

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.

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

 

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

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

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

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.

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

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

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.

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

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

Rank Amateur:

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

Now *that's* funny!

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

Anonymous:

[...Although I'm
not really sure what would be the proper tool for fixing this one, fire
I would guess.

Firing would be a better solution.

Sean:

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

Hence the expression, "A little knowledge is a dangerous thing." --Alexander Pope

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.

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.

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.

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).

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?

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?

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

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

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

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

 

yeah but there's a catch{} to everything

 

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.

Anonymous:

my eyes are bleeding

I'm right there with you.