The Daily WTF: Curious Perversions in Information Technology

2011-05-03 Reply Admin

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.

He obviously did not realise how and where it was useful.

2011-05-03 Reply Admin

illtiz:
Matthew Vines:

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

I demand this be turned blue, Alex.

I'm with you. I'm still wondering how he can get access to any known or unknown programmer's source code. So: show me the bugs in the 14th Soyuz' mission's software? Pretty please?

GalacticCowboy · 2011-05-03 Reply Admin

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.

On Humor Error Resume WTF

In my case, I don't know any programmers named Trent, but I could find the story completely believable with a simple name substitution. Your mileage may vary.

2011-05-03 Reply Admin

Oh, well, VB6 again...

Back in the day my company developed software targeted to SCO Xenix/Unix, and the installation script was done in sh.

Well, the company managed to hire a brillant person as CIO, but he didn't have a clue about Unix. He got the responsability of creating the shell scripts (go figure), and of course, the first versions were error-prone, as he didn't have idea of correctly setting the floppy disk devices.

So, each time we tried to install a product, we had to manually edit the scripts.

Fast forward some months, and all of sudden... the scripts doesn't complain, oh great!

But the software installation was failing anyway. WTF?

So I opened the install script, and found "On Error Resume Next" in shell:

mount /dev/fd0 /mnt > /dev/null cp /mnt/wtf_file.tgz /root > /dev/null chmod +x /mnt/wtf_file.tgz > /dev/null /root/wtf_file.tgz > /dev/null echo Installation successful

As many say... TRWTF is not the language... is the user.

2011-05-03 Reply Admin

Vista? Seriously? Why do you use Vista at work? Why do you use Vista at ANYTHING?

2011-05-03 Reply Admin

Jaime:
Nagesh:
Jaime:
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.

jaime, in C I remember we always are told to throw exception to the highest caller or was that C++? i m having memory trubles.

I've got bad news for you... C doesn't support exceptions at all.

I have bad news for you, too...

YHBT. YHL. HAND! (or in my case, TYCA!)

2011-05-03 Reply Admin

Nagesh:
Jaime:
Nagesh:
Jaime:
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.

jaime, in C I remember we always are told to throw exception to the highest caller or was that C++? i m having memory trubles.

I've got bad news for you... C doesn't support exceptions at all.

I have bad news for you, too...

YHBT. YHL. HAND! (or in my case, TYCA!)

TYCA? Take Your Computer Away? Type Your C Applications? Trim Your Cute A$$?

Ritchie70 · 2011-05-03 Reply Admin

It depends on the user base.

A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

2011-05-03 Reply Admin

QJ:
Nagesh:
Jaime:
Nagesh:
Jaime:
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.

jaime, in C I remember we always are told to throw exception to the highest caller or was that C++? i m having memory trubles.

I've got bad news for you... C doesn't support exceptions at all.

I have bad news for you, too...

YHBT. YHL. HAND! (or in my case, TYCA!)

TYCA? Take Your Computer Away? Type Your C Applications? Trim Your Cute A$$?

Thank You, Come Again!

Jaime · 2011-05-03 Reply Admin

Nagesh:
Jaime:
Nagesh:
Jaime:
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.

jaime, in C I remember we always are told to throw exception to the highest caller or was that C++? i m having memory trubles.

I've got bad news for you... C doesn't support exceptions at all.

I have bad news for you, too...

YHBT. YHL. HAND! (or in my case, TYCA!)

I'm so proud of you. Saying something stupid is such a fine art that only a select few have mastered it.

Trolling is supposed to bait someone into a flame war. Simpy dropping inaccurate facts is the lamest troll ever.

2011-05-03 Reply Admin

Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

As in: "Why is my computer telling me I am bad, that I am an invalid?"

2011-05-03 Reply Admin

Jaime:
Nagesh:
Jaime:
Nagesh:
Jaime:
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.

jaime, in C I remember we always are told to throw exception to the highest caller or was that C++? i m having memory trubles.

I've got bad news for you... C doesn't support exceptions at all.

I have bad news for you, too...

YHBT. YHL. HAND! (or in my case, TYCA!)
I'm so proud of you. Saying something stupid is such a fine art that only a select few have mastered it.

Trolling is supposed to bait someone into a flame war. Simpy dropping inaccurate facts is the lamest troll ever.

That sounded like a flame to me.

Troll successful?

2011-05-03 Reply Admin

Anon:
Jaime:
Nagesh:
Jaime:
Nagesh:
Jaime:
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.

jaime, in C I remember we always are told to throw exception to the highest caller or was that C++? i m having memory trubles.

I've got bad news for you... C doesn't support exceptions at all.

I have bad news for you, too...

YHBT. YHL. HAND! (or in my case, TYCA!)
I'm so proud of you. Saying something stupid is such a fine art that only a select few have mastered it.

Trolling is supposed to bait someone into a flame war. Simpy dropping inaccurate facts is the lamest troll ever.

That sounded like a flame to me.

Troll successful?

Don't call me troll, madarhorn!

2011-05-03 Reply Admin

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

There are no great programmers.

Everyone writes bad code.

Nagesh · 2011-05-03 Reply Admin

[quote user="Nagesh"] Troll successful?[/quote] Don't call me troll, madarhorn![/quote]

If you plan to imiate me, use corect Hindi speling of words, madarchod.

2011-05-03 Reply Admin

Matt Westwood:
Gunslinger:
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.

Your facts and logic are flawed. A person who writes good code will suddenly write bad code just because they get a degree?

People who learn how to write code by getting immediate hands-on experience maintaining an existing system, learning to program by imitation, are frequently better at writing computer programs than those who have learnt in an academic environment where the examples of code being generated are perhaps artificial and divorced from real-world apps.

It is also often the case that graduates of computer software courses have handed in assignments which may have been the result of collaborative effort, thereby not providing a truly honest appraisal of the ability of the student.

When that graduate appears on the doorstep of a place of industry, it is more likely that the reputation of that graduate will be sufficient to ensure that the task he/she is initially assigned will be more demanding than that of the new starter mentioned above. Hence the chances of that new graduate making a less than successful job of the task assigned are that much higher.

Hence the reputation for CS graduates to be worth less than those who have learned their craft the hard way. Whether these things are generally true or not I can't say - but the colleagues of mine with the fanciest degrees and diplomas in computer-related disciplines have often been those whose code is of lowest quality.

It's true that not all CS majors are good programmers, however those who go through the theory first and then get the experience are a hell of a lot more useful than those who don't ever touch the theory. The latter are the kind who think bubblesort is 'neat'

2011-05-03 Reply Admin

socknet:
Matt Westwood:
Gunslinger:
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.

Your facts and logic are flawed. A person who writes good code will suddenly write bad code just because they get a degree?

People who learn how to write code by getting immediate hands-on experience maintaining an existing system, learning to program by imitation, are frequently better at writing computer programs than those who have learnt in an academic environment where the examples of code being generated are perhaps artificial and divorced from real-world apps.

It is also often the case that graduates of computer software courses have handed in assignments which may have been the result of collaborative effort, thereby not providing a truly honest appraisal of the ability of the student.

When that graduate appears on the doorstep of a place of industry, it is more likely that the reputation of that graduate will be sufficient to ensure that the task he/she is initially assigned will be more demanding than that of the new starter mentioned above. Hence the chances of that new graduate making a less than successful job of the task assigned are that much higher.

Hence the reputation for CS graduates to be worth less than those who have learned their craft the hard way. Whether these things are generally true or not I can't say - but the colleagues of mine with the fanciest degrees and diplomas in computer-related disciplines have often been those whose code is of lowest quality.

It's true that not all CS majors are good programmers, however those who go through the theory first and then get the experience are a hell of a lot more useful than those who don't ever touch the theory. The latter are the kind who think bubblesort is 'neat'

Last time I saw a bubblesort (in Java, no less) it had been written by the hot shot whom we had recently spent (as a company) a significant sum of money sending away to be educated because he was "promising". He used to lord it over the rest of the plebs on his section. When his bubblesort was found (with a cut-and-pasted multiplicty of 4) questions started to be asked about the efficacy of academic CS education. Unfortunately it resulted in no further training whatsoever being offered to any members of the s/w dev dept.

2011-05-03 Reply Admin

C-Octothorpe:
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.

Best way to solve any problem,

try{
// Something
}catch(Exception e){}

2011-05-03 Reply Admin

QJ:
socknet:
Matt Westwood:
Gunslinger:
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.

Your facts and logic are flawed. A person who writes good code will suddenly write bad code just because they get a degree?

People who learn how to write code by getting immediate hands-on experience maintaining an existing system, learning to program by imitation, are frequently better at writing computer programs than those who have learnt in an academic environment where the examples of code being generated are perhaps artificial and divorced from real-world apps.

It is also often the case that graduates of computer software courses have handed in assignments which may have been the result of collaborative effort, thereby not providing a truly honest appraisal of the ability of the student.

When that graduate appears on the doorstep of a place of industry, it is more likely that the reputation of that graduate will be sufficient to ensure that the task he/she is initially assigned will be more demanding than that of the new starter mentioned above. Hence the chances of that new graduate making a less than successful job of the task assigned are that much higher.

Hence the reputation for CS graduates to be worth less than those who have learned their craft the hard way. Whether these things are generally true or not I can't say - but the colleagues of mine with the fanciest degrees and diplomas in computer-related disciplines have often been those whose code is of lowest quality.

It's true that not all CS majors are good programmers, however those who go through the theory first and then get the experience are a hell of a lot more useful than those who don't ever touch the theory. The latter are the kind who think bubblesort is 'neat'

Last time I saw a bubblesort (in Java, no less) it had been written by the hot shot whom we had recently spent (as a company) a significant sum of money sending away to be educated because he was "promising". He used to lord it over the rest of the plebs on his section. When his bubblesort was found (with a cut-and-pasted multiplicty of 4) questions started to be asked about the efficacy of academic CS education. Unfortunately it resulted in no further training whatsoever being offered to any members of the s/w dev dept.

Knowing theory is important regardless of how good a "programmer" you are. Sure there are a lot of bad CS programmers, but that doesn't make the statement any less true.

2011-05-03 Reply Admin

Nagesh:
Nagesh:
Troll successful? Don't call me troll, madarhorn!

If you plan to imiate me, use corect Hindi speling of words, madarchod.

I like madarhorn better. It made all of my faces burst into laughter!

2011-05-03 Reply Admin

C0ndom:
C-Octothorpe:
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.

Best way to solve any problem,
try{
// Something
}catch(Exception e){}

Better:

try{
// Something
}catch(Throwable t){}

frits · 2011-05-03 Reply Admin

QJ:
C0ndom:
C-Octothorpe:
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.

Best way to solve any problem,
try{
// Something
}catch(Exception e){}
. Better:
try{
// Something
}catch(Throwable t){}

. Best:

try
{
// Anything
}catch(...){}

2011-05-03 Reply Admin

Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

Maybe, and I have developed both web and desktop apps targeted to both ends of the spectrum, meaning power users who appreciate a nice stack trace to those who call tech support when Caps lock is enabled... Generally, they would like to be notified that what they thought they just did, didn't go through (i.e. transaction rolled back because something failed, etc.).

I think we are talking at cross purposes here. I think those that argue "don't show user scary computer voodoo stuff" are talking about an application or transaction of absolutely no consequence (game, etc.). But any business users who use a system where their interactions drive reports, work flows, etc., want to be notified that the DB just took a shit and didn't save their month-end report, and that they can retry or call tech support, etc.

2011-05-03 Reply Admin

frits:

Best:

try
{
// Anything
}catch(...){}

Almost...

try { // some shitty, exception prone code goes here } catch { // profit? }

Don't know about java, but in .net you can have a parameterless catch, which is exactly as useful as you would imagine. I'm sure it exists only to swallow exceptions without logging any kind of details.

2011-05-03 Reply Admin

C-Octothorpe:
Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

Maybe, and I have developed both web and desktop apps targeted to both ends of the spectrum, meaning power users who appreciate a nice stack trace to those who call tech support when Caps lock is enabled... Generally, they would like to be notified that what they thought they just did, didn't go through (i.e. transaction rolled back because something failed, etc.).

I think we are talking at cross purposes here. I think those that argue "don't show user scary computer voodoo stuff" are talking about an application or transaction of absolutely no consequence (game, etc.). But any business users who use a system where their interactions drive reports, work flows, etc., want to be notified that the DB just took a shit and didn't save their month-end report, and that they can retry or call tech support, etc.

Ultimately the user has a right to know what happened when they pressed a button and it didn't do as expected or advertised.

If the programmer can not explain (or even understand) what actually happens when a particular exception is thrown, or know what to do to recover from it, then the job has not been done adequately. Deciding on the language in which to report back to the user ("Aw cr*p! The browser's gone wrong! Try again!" or whatever) is more of a management / UI specialist task than a programming task, but ultimately it boils down to: the user has a right to know what's up.

Nagesh · 2011-05-03 Reply Admin

C-Octothorpe:
Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

Maybe, and I have developed both web and desktop apps targeted to both ends of the spectrum, meaning power users who appreciate a nice stack trace to those who call tech support when Caps lock is enabled... Generally, they would like to be notified that what they thought they just did, didn't go through (i.e. transaction rolled back because something failed, etc.).

I think we are talking at cross purposes here. I think those that argue "don't show user scary computer voodoo stuff" are talking about an application or transaction of absolutely no consequence (game, etc.). But any business users who use a system where their interactions drive reports, work flows, etc., want to be notified that the DB just took a shit and didn't save their month-end report, and that they can retry or call tech support, etc.

Business user who work in bank is moron of highest order. These people manage whole america's money is one scray thought to me. They don't want to learn because IT tech suport is easy button for them. Just call IT abuse poor poeple and get along with daily life and play golf with there friends.

2011-05-03 Reply Admin

QJ:
C-Octothorpe:
Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

Maybe, and I have developed both web and desktop apps targeted to both ends of the spectrum, meaning power users who appreciate a nice stack trace to those who call tech support when Caps lock is enabled... Generally, they would like to be notified that what they thought they just did, didn't go through (i.e. transaction rolled back because something failed, etc.).

I think we are talking at cross purposes here. I think those that argue "don't show user scary computer voodoo stuff" are talking about an application or transaction of absolutely no consequence (game, etc.). But any business users who use a system where their interactions drive reports, work flows, etc., want to be notified that the DB just took a shit and didn't save their month-end report, and that they can retry or call tech support, etc.

Ultimately the user has a right to know what happened when they pressed a button and it didn't do as expected or advertised.

If the programmer can not explain (or even understand) what actually happens when a particular exception is thrown, or know what to do to recover from it, then the job has not been done adequately. Deciding on the language in which to report back to the user ("Aw cr*p! The browser's gone wrong! Try again!" or whatever) is more of a management / UI specialist task than a programming task, but ultimately it boils down to: the user has a right to know what's up.

The only reason for a class not to handle an exception is if (a) the class doesn't have the information to handle it adequately, in which case it should be thrown and handled elsewhere or (b) the programmer doesn't know how to handle the exception adequately.

I challenge someone to come up with an exception which shouldn't be handled at all.

Too many people here seem to think that catching an exception means that you cannot alert the user that it took place.

2011-05-03 Reply Admin

QJ:
C-Octothorpe:
Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

Maybe, and I have developed both web and desktop apps targeted to both ends of the spectrum, meaning power users who appreciate a nice stack trace to those who call tech support when Caps lock is enabled... Generally, they would like to be notified that what they thought they just did, didn't go through (i.e. transaction rolled back because something failed, etc.).

I think we are talking at cross purposes here. I think those that argue "don't show user scary computer voodoo stuff" are talking about an application or transaction of absolutely no consequence (game, etc.). But any business users who use a system where their interactions drive reports, work flows, etc., want to be notified that the DB just took a shit and didn't save their month-end report, and that they can retry or call tech support, etc.

Ultimately the user has a right to know what happened when they pressed a button and it didn't do as expected or advertised.

If the programmer can not explain (or even understand) what actually happens when a particular exception is thrown, or know what to do to recover from it, then the job has not been done adequately. Deciding on the language in which to report back to the user ("Aw cr*p! The browser's gone wrong! Try again!" or whatever) is more of a management / UI specialist task than a programming task, but ultimately it boils down to: the user has a right to know what's up.

So, you're saying what I said then: error messages are good?

Also regarding your comment about only l33t developers recover from exception is bullshit. How many exceptions can you realistically recover from?

You try to save "report"
Request posts to the server
Passes validation, call service.Save(objectToSave)
Server throws exception because the intertubes are clogged and can't reach the endpoint.
[supply recovery pseudo code here, pls]

I mean, there are some scenarios where you may be able to recover from an exception, but in most cases the proper way to "handle" an exception is to cleanup any resources, rollback transactions, etc., then finally let the caller know that the method call failed.

2011-05-03 Reply Admin

socknet:
QJ:
C-Octothorpe:
Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

Maybe, and I have developed both web and desktop apps targeted to both ends of the spectrum, meaning power users who appreciate a nice stack trace to those who call tech support when Caps lock is enabled... Generally, they would like to be notified that what they thought they just did, didn't go through (i.e. transaction rolled back because something failed, etc.).

I think we are talking at cross purposes here. I think those that argue "don't show user scary computer voodoo stuff" are talking about an application or transaction of absolutely no consequence (game, etc.). But any business users who use a system where their interactions drive reports, work flows, etc., want to be notified that the DB just took a shit and didn't save their month-end report, and that they can retry or call tech support, etc.

Ultimately the user has a right to know what happened when they pressed a button and it didn't do as expected or advertised.

If the programmer can not explain (or even understand) what actually happens when a particular exception is thrown, or know what to do to recover from it, then the job has not been done adequately. Deciding on the language in which to report back to the user ("Aw cr*p! The browser's gone wrong! Try again!" or whatever) is more of a management / UI specialist task than a programming task, but ultimately it boils down to: the user has a right to know what's up.

The only reason for a class not to handle an exception is if (a) the class doesn't have the information to handle it adequately, in which case it should be thrown and handled elsewhere or (b) the programmer doesn't know how to handle the exception adequately.

I challenge someone to come up with an exception which shouldn't be handled at all.

Too many people here seem to think that catching an exception means that you cannot alert the user that it took place.

Okay so there's 2 sorts of exception:

a) The sort caused by dodgy data (which includes badly-formatted files, etc.) that is outside of the control of the program, against which the programmer should defend against. In this case the exception should be caught and processed appropriate, which means issuing a message to the inputter of data reporting on the fact that the data's duff.

b) Something internal to the workings of the program caused by an up-till-now unfound bug (e.g. overflow or div-by-zero caused by inadequate bounds checking). The latter also ought to be caught (by the aforementioned "catch (Exception e)" or whatever, and at the very minimum logged at ERROR level and the program ought to humbly mention to the user that "an unexpected error happened - please contact our tech support" (along with a unique number / code for tracking purposes) or whatever.

I would like to believe that the above is a non-controversial description of what ought to be the case for any application.

2011-05-03 Reply Admin

Nagesh:

Nagesh:
Don't call me troll, madarhorn!

If you plan to imiate me, use corect Hindi speling of words, madarchod.

Why are you arguing with yourself?

2011-05-03 Reply Admin

C-Octothorpe:
QJ:
C-Octothorpe:
Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

Maybe, and I have developed both web and desktop apps targeted to both ends of the spectrum, meaning power users who appreciate a nice stack trace to those who call tech support when Caps lock is enabled... Generally, they would like to be notified that what they thought they just did, didn't go through (i.e. transaction rolled back because something failed, etc.).

I think we are talking at cross purposes here. I think those that argue "don't show user scary computer voodoo stuff" are talking about an application or transaction of absolutely no consequence (game, etc.). But any business users who use a system where their interactions drive reports, work flows, etc., want to be notified that the DB just took a shit and didn't save their month-end report, and that they can retry or call tech support, etc.

Ultimately the user has a right to know what happened when they pressed a button and it didn't do as expected or advertised.

If the programmer can not explain (or even understand) what actually happens when a particular exception is thrown, or know what to do to recover from it, then the job has not been done adequately. Deciding on the language in which to report back to the user ("Aw cr*p! The browser's gone wrong! Try again!" or whatever) is more of a management / UI specialist task than a programming task, but ultimately it boils down to: the user has a right to know what's up.

So, you're saying what I said then: error messages are good?

Also regarding your comment about only l33t developers recover from exception is bullshit. How many exceptions can you realistically recover from?

You try to save "report"

Request posts to the server

Passes validation, call service.Save(objectToSave)

Server throws exception because the intertubes are clogged and can't reach the endpoint.

[supply recovery pseudo code here, pls]

I mean, there are some scenarios where you may be able to recover from an exception, but in most cases the proper way to "handle" an exception is to cleanup any resources, rollback transactions, etc., then finally let the caller know that the method call failed.

catch(TubesCloggedException tce) { //attempt recovery ... (try something)

// otherwise, cleanup code ...

// then, notify user code ...

//throw Exception throw new FailedSaveException(tce.usefulStuff); }

done.

Here, you have tried to recover, tested if recovery worked and then if it hasn't you clean up whatever mess you created, notify the user of the problem encountered and then send a more specific (hence more useful) exception to the calling class.

Even if all you did was the last of these steps, it is still much much better than just passing the more general exception down the chain.

frits · 2011-05-03 Reply Admin

C-Octothorpe:
frits:
Best:
try
{
// Anything
}catch(...){}
Almost...

try { // some shitty, exception prone code goes here } catch { // profit? }

Don't know about java, but in .net you can have a parameterless catch, which is exactly as useful as you would imagine. I'm sure it exists only to swallow exceptions without logging any kind of details.

In C++ you can throw anything, not just exceptions. i.e.

throw ("Baloney Sandwich");

2011-05-03 Reply Admin

QJ:
socknet:
QJ:
C-Octothorpe:
Ritchie70:
It depends on the user base.
A sufficiently naive user base should just be left alone. The software should move heaven and earth, as best it can, to recover, but there are some groups of users you just don't want to tell.

Some of them will panic. Some will freak o ut. Some will start crying.

Maybe, and I have developed both web and desktop apps targeted to both ends of the spectrum, meaning power users who appreciate a nice stack trace to those who call tech support when Caps lock is enabled... Generally, they would like to be notified that what they thought they just did, didn't go through (i.e. transaction rolled back because something failed, etc.).

I think we are talking at cross purposes here. I think those that argue "don't show user scary computer voodoo stuff" are talking about an application or transaction of absolutely no consequence (game, etc.). But any business users who use a system where their interactions drive reports, work flows, etc., want to be notified that the DB just took a shit and didn't save their month-end report, and that they can retry or call tech support, etc.

Ultimately the user has a right to know what happened when they pressed a button and it didn't do as expected or advertised.

If the programmer can not explain (or even understand) what actually happens when a particular exception is thrown, or know what to do to recover from it, then the job has not been done adequately. Deciding on the language in which to report back to the user ("Aw cr*p! The browser's gone wrong! Try again!" or whatever) is more of a management / UI specialist task than a programming task, but ultimately it boils down to: the user has a right to know what's up.

The only reason for a class not to handle an exception is if (a) the class doesn't have the information to handle it adequately, in which case it should be thrown and handled elsewhere or (b) the programmer doesn't know how to handle the exception adequately.

I challenge someone to come up with an exception which shouldn't be handled at all.

Too many people here seem to think that catching an exception means that you cannot alert the user that it took place.

Okay so there's 2 sorts of exception:

a) The sort caused by dodgy data (which includes badly-formatted files, etc.) that is outside of the control of the program, against which the programmer should defend against. In this case the exception should be caught and processed appropriate, which means issuing a message to the inputter of data reporting on the fact that the data's duff.

b) Something internal to the workings of the program caused by an up-till-now unfound bug (e.g. overflow or div-by-zero caused by inadequate bounds checking). The latter also ought to be caught (by the aforementioned "catch (Exception e)" or whatever, and at the very minimum logged at ERROR level and the program ought to humbly mention to the user that "an unexpected error happened - please contact our tech support" (along with a unique number / code for tracking purposes) or whatever.

I would like to believe that the above is a non-controversial description of what ought to be the case for any application.

Oh okay, and a third one:

c) The infrastructure's overloaded or broken. Wah-deh-vur ...

2011-05-03 Reply Admin

socknet:
The only reason for a class not to handle an exception is if (a) the class doesn't have the information to handle it adequately, in which case it should be thrown and handled elsewhere or (b) the programmer doesn't know how to handle the exception adequately.
I challenge someone to come up with an exception which shouldn't be handled at all.

Too many people here seem to think that catching an exception means that you cannot alert the user that it took place.

See my post above.

Also what about c) you CAN'T handle the exception. Fuck people, if the DB is down, the DB is down.

Unless of course I'm not aligned with your definition of "handle", because my definition of handle is if you have the exception in a catch block, it's handled. What you do with it from that point on is very specific to many factors I'm not going to mention here for brevity...

There have been scenarios where, for example, I have tried to log something, but the logging failed, then you try again maybe 10 more times with 1 second between each attempt. At which point you can either try another persistence medium or lose the log.

2011-05-03 Reply Admin

Nagesh:
Nagesh:
Don't call me troll, madarhorn!
If you plan to imiate me, use corect HindiSwedish speling of words, madarchod Matterhorn.

FTFY

Nagesh · 2011-05-03 Reply Admin

Star Fox:
Nagesh:

Nagesh:
Don't call me troll, madarhorn!

If you plan to imiate me, use corect Hindi speling of words, madarchod.
Why are you arguing with yourself?

DON'T stupid with me!

Nagesh · 2011-05-03 Reply Admin

The Corrector:
Nagesh:
Nagesh:
Don't call me troll, madarhorn!
If you plan to imiate me, use corect HindiSwedish speling of words, madarchod Matterhorn.
FTFY

Materhorn is not hindi word!

2011-05-03 Reply Admin

C-Octothorpe:
See my post above.
Also what about c) you CAN'T handle the exception. Fuck people, if the DB is down, the DB is down.

Unless of course I'm not aligned with your definition of "handle", because my definition of handle is if you have the exception in a catch block, it's handled. What you do with it from that point on is very specific to many factors I'm not going to mention here for brevity...

There have been scenarios where, for example, I have tried to log something, but the logging failed, then you try again maybe 10 more times with 1 second between each attempt. At which point you can either try another persistence medium or lose the log.

How you handle something is as you say dependent on the scenario - however I would absolutely catch and handle an exception thrown by not being able to connect to the DB.

inside your catch statement, you might put retry attempts, maybe try a different datasource, maybe just show an error dialog for the user and then pass the exception down the chain. what you shouldn't do is just ignore it.

Can you fix everything? no, of course not. But you can still take positive action.

2011-05-03 Reply Admin

socknet:
catch(TubesCloggedException tce) { //attempt recovery ... (try something)
// otherwise, cleanup code ...

// then, notify user code ...

//throw Exception throw new FailedSaveException(tce.usefulStuff); }

done.

Here, you have tried to recover, tested if recovery worked and then if it hasn't you clean up whatever mess you created, notify the user of the problem encountered and then send a more specific (hence more useful) exception to the calling class.

Even if all you did was the last of these steps, it is still much much better than just passing the more general exception down the chain.

Glad you explained what you meant by handle...

And I'm not too sure that there is much to gain from always handling an exception. If you're not going to do anything with it, other than wrap it in another exception for the hell of it, then let it fly. Obviously there is a point (usually service layer) where you stop the exception, log all the exception details, and rethrow, with user-friendly, localized goodness without any stack info, etc. which may lead to a security issues.

Either way, I'm pretty sure we're all on the same page with this...

2011-05-03 Reply Admin

C-Octothorpe:

Glad you explained what you meant by handle...

And I'm not too sure that there is much to gain from always handling an exception. If you're not going to do anything with it, other than wrap it in another exception for the hell of it, then let it fly. Obviously there is a point (usually service layer) where you stop the exception, log all the exception details, and rethrow, with user-friendly, localized goodness without any stack info, etc. which may lead to a security issues.

Either way, I'm pretty sure we're all on the same page with this...

yeah I think we probably share the same view on this. I do think that from a theoretical perspective (infinite resources with infinite time), all exceptions should be caught and handled. I am aware that this is not always practical or cost effective though. Most companies wouldn't want to pay someone to spend time covering every single exception corner case when they could be adding more functionality for the same cost.

Nagesh · 2011-05-03 Reply Admin

Darth Paul:
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.

He obviously did not realise how and where it was useful.

Not being expert in VB, I cannot make comment

2011-05-03 Reply Admin

Nagesh:
The Corrector:
Nagesh:
Nagesh:
Don't call me troll, madarhorn!
If you plan to imiate me, use corect HindiSwedish speling of words, madarchod Matterhorn.
FTFY

Materhorn is not hindi word!

Also not Swedish. GIYF.

2011-05-03 Reply Admin

Nagesh:
Star Fox:
Nagesh:

Nagesh:
Don't call me troll, madarhorn!

If you plan to imiate me, use corect Hindi speling of words, madarchod.
Why are you arguing with yourself?

DON'T stupid with me!

Obviously do a good enough job of it just on your own...

Bahen Chod...

Nagesh · 2011-05-03 Reply Admin

C-Octothorpe:
Nagesh:
Star Fox:
Nagesh:

Nagesh:
Don't call me troll, madarhorn!

If you plan to imiate me, use corect Hindi speling of words, madarchod.
Why are you arguing with yourself?

DON'T stupid with me!

Obviously do a good enough job of it just on your own...

Bahen Chod...

Correct Hindi word! Your really learning well to annoy people like me.

2011-05-03 Reply Admin

socknet:
C-Octothorpe:

Glad you explained what you meant by handle...

And I'm not too sure that there is much to gain from always handling an exception. If you're not going to do anything with it, other than wrap it in another exception for the hell of it, then let it fly. Obviously there is a point (usually service layer) where you stop the exception, log all the exception details, and rethrow, with user-friendly, localized goodness without any stack info, etc. which may lead to a security issues.

Either way, I'm pretty sure we're all on the same page with this...

yeah I think we probably share the same view on this. I do think that from a theoretical perspective (infinite resources with infinite time), all exceptions should be caught and handled. I am aware that this is not always practical or cost effective though. Most companies wouldn't want to pay someone to spend time covering every single exception corner case when they could be adding more functionality for the same cost.

Bear in mind that there are types of exception thrown in Java that you have to put the class that declares it in a try/catch block. These are the circ where duffers put "catch (Exception e){}" and call it "handled". I'd call them "fumbled": caught and immediately dropped.

2011-05-03 Reply Admin

QJ:
Nagesh:
The Corrector:
Nagesh:
Nagesh:
Don't call me troll, madarhorn!
If you plan to imiate me, use corect HindiSwedish speling of words, madarchod Matterhorn.
FTFY

Materhorn is not hindi word!

Also not Swedish. GIYF.

Not being an expert in Swedish, I cannot comment.

2011-05-03 Reply Admin

QJ:
Nagesh:
The Corrector:
Nagesh:
Nagesh:
Don't call me troll, madarhorn!
If you plan to imiate me, use corect HindiSwedish speling of words, madarchod Matterhorn.
FTFY

Materhorn is not hindi word!

Also not Swedish. GIYF.

Who hasn't done something like this?

[img]http://upload.wikimedia.org/wikipedia/commons/a/aa/Klein_Matterhorn_-Zermatt-Switzerland-2005-_04.JPG[/url]

Speaking of Error'd, why are they using a comma for an apostrophe?

2011-05-03 Reply Admin

QJ:
Something internal to the workings of the program caused by an up-till-now unfound bug (e.g. overflow or div-by-zero caused by inadequate bounds checking). The latter *also* ought to be caught (by the aforementioned "catch (Exception e)" or whatever, and at the very minimum *logged* at ERROR level *and* the program ought to humbly mention to the user that "an unexpected error happened - please contact our tech support" (along with a unique number / code for tracking purposes) or whatever.

I wouldn't make any expectations of the user. Essentially 100% of them don't read any message boxes, errors, warnings, etc.

Depending on context, the program could stop accepting input, contact tech support itself and then include enough information to backtrack what the user did, to restore the system to a known state, make the fix, and then redo correctly.

Having said that, unless this philosophy is built-in from the start, it's very hard to do! It is done though, especially systems which rely on stateful third party entities.

2011-05-03 Reply Admin

QJ:
Nagesh:
The Corrector:
Nagesh:
Nagesh:
Don't call me troll, madarhorn!
If you plan to imiate me, use corect HindiSwedish speling of words, madarchod Matterhorn.
FTFY

Materhorn is not hindi word!

Also not Swedish. GIYF.

Who hasn't done something like this?

[image]

Speaking of Error'd, why are they using a comma for an apostrophe?

2011-05-03 Reply Admin

QJ:
socknet:
C-Octothorpe:

Glad you explained what you meant by handle...

And I'm not too sure that there is much to gain from always handling an exception. If you're not going to do anything with it, other than wrap it in another exception for the hell of it, then let it fly. Obviously there is a point (usually service layer) where you stop the exception, log all the exception details, and rethrow, with user-friendly, localized goodness without any stack info, etc. which may lead to a security issues.

Either way, I'm pretty sure we're all on the same page with this...

yeah I think we probably share the same view on this. I do think that from a theoretical perspective (infinite resources with infinite time), all exceptions should be caught and handled. I am aware that this is not always practical or cost effective though. Most companies wouldn't want to pay someone to spend time covering every single exception corner case when they could be adding more functionality for the same cost.

Bear in mind that there are types of exception thrown in Java that you have to put the class that declares it in a try/catch block. These are the circ where duffers put "catch (Exception e){}" and call it "handled". I'd call them "fumbled": caught and immediately dropped.

That is probably the IDE putting that catch there, or just laziness.

(the type you are referring to are called checked exceptions)

The Vista Fix

Leave a comment on “The Vista Fix”