Comment On The Vista Fix

On Error Comment

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

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.

s/Trent/Steve/

Fixed that for ya.

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

Power Troll:

On Error Resume Comment

FTFY

Cool story, bro.

dohpaz42:

Power Troll:

On Error Resume Comment

FTFY

On Troll First Post

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.

The real WTF is support for Vista? Right??

"Poring through the code"

Thanks for getting that right.

Power Troll:

On Error Comment

TRWTF is comments.

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

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

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

Fix: Obvious.

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

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 is good thing Vista fix was implemented on DNA testing algorithm.

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.

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.

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.

"Poring"? Was it stinky or filmy?

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

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.

Mr. Cranky Language Person:

"Poring through the code"

Thanks for getting that right.

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

As in, gasoline.

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.

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.

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.

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.

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?

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.

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?

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!

}

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.

blah:

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

This, and the lack of source control is almost a given.

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.

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.

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.

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.

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!?!?!?!

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.

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

On Error Update Resume

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 ?

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'?

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.

Wasn't he living in Pakistan?

I though Indians hated Pakistanis.

Why would he be your idol?

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.

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

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

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.

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.