The Vista Fix

« Return to Article
  • Power Troll 2011-05-02 12:34
    On Error Comment
  • D Martensson 2011-05-02 12:36
    I had a collegue 5-6 years ago that used the same "fix" in a conversion program, another collegue invented some very new bad words when trying to upgrade it later ;)
  • WC 2011-05-02 12:39
    At some point, you've got 'new' and 'old' backwards. I suspect Trent implemented it in the old version, and the submitter implemented it in the new version.
  • GalacticCowboy 2011-05-02 12:42
    s/Trent/Steve/

    Fixed that for ya.
  • Zolcos 2011-05-02 12:42
    That was probably the right decision. It doesn't really fix anything, of course, but doing it the right way would just waste a lot more time. This way he can get to finishing the rewrite.
    WC:
    At some point, you've got 'new' and 'old' backwards. I suspect Trent implemented it in the old version, and the submitter implemented it in the new version.

    I get the feeling that both the new and old versions were 'old' and not part of his rewrite
  • dohpaz42 2011-05-02 12:52
    Power Troll:
    On Error Resume Comment


    FTFY
  • Brogrammer 2011-05-02 12:55
    Cool story, bro.
  • Roman 2011-05-02 12:56
    dohpaz42:
    Power Troll:
    On Error Resume Comment


    FTFY


    On Troll First Post
  • Vilx- 2011-05-02 12:59
    That's not the Vista Fix! That's the Universal Panacea! He has finally done it! He has found the way to make any software run error-free!

    Well, as long as that software is written in VB6 at least.
  • Bryan the K 2011-05-02 12:59
    The real WTF is support for Vista? Right??
  • Mr. Cranky Language Person 2011-05-02 13:01
    "Poring through the code"

    Thanks for getting that right.
  • frits 2011-05-02 13:04
    Power Troll:
    On Error Comment

    TRWTF is comments.
  • blah 2011-05-02 13:05
    TRWTF is not performing a diff. Presumably TRRWTF is no source control.
  • DCRoss 2011-05-02 13:11
    Problem: Software is showing error messages to user while running.

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

    Fix: Obvious.
  • Brian 2011-05-02 13:15
    Sadly, the Vista Fix requires you to dynamically generate all of your controls. Otherwise, users might still see errors when one of your controls fails to load (e.g., because the user is missing the .ocx file).
  • Nagesh 2011-05-02 13:33
    I did one class for VB6 that I ashamed to mention

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

  • Al Jaseera 2011-05-02 13:36
    It is good thing Vista fix was implemented on DNA testing algorithm.
  • Niten 2011-05-02 13:40
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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



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

    And plenty of people with computer science degrees write bad code.
  • Fact Checker 2011-05-02 13:42
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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



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

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


    Indeed. My facts say that not one great programmer has a Computer Science degree. Also: every person with a computer science degree writes bad code.
  • Nagesh 2011-05-02 13:44
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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



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

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


    Structure thinking v/s unstructure thinking. That is pipe dream. Name 4 great programmer candidates who did not have CS degree and I will show bugs in their code.
  • Jo Poser 2011-05-02 13:45
    "Poring"? Was it stinky or filmy?

    nobis... you can only spell "America" with nobis. Or something similarly stupid and confusing.
  • trtrwtf 2011-05-02 13:45
    Fact Checker:

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


    I know a great programmer with a computer science degree. Actually, two. Three, now I come to think of it. Go check your facts.
  • fritters 2011-05-02 13:49
    Mr. Cranky Language Person:
    "Poring through the code"

    Thanks for getting that right.


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

    As in, gasoline.
  • PedanticCurmudgeon 2011-05-02 13:50
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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

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

    Oh, and I walked to school uphill, both ways, etc.
  • C-Octothorpe 2011-05-02 13:51
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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



    It's really, really sad to see how often I see supposedly "senior" or "intermediate" developers writing code like this:
    try
    
    {
    var returnValue = int.Parse(stringVal);
    return returnValue;
    }
    catch
    {
    // something is wrong...
    return null;
    }

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

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


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

    I've had discussions with developers who are convinced that an application should never throw an error.
  • Matthew Vines 2011-05-02 14:17
    Nagesh:
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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



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

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


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


    Name 4 programmers and I will show bugs in their code.
  • Pedantic CBE 2011-05-02 14:22
    C-Octothorpe:

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

    Well, I can see where that idea is coming from.

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

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

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

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

    *Command-line on the o0ther hand should die as quickly as possible with a good error message so the user isn't sat for ages waiting for it to fail on their erroneous input.
  • Jeff 2011-05-02 14:23
    DCRoss:
    Problem: Software is showing error messages to user while running.

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

    Fix: Obvious.
    Shoot user?
  • DaveK 2011-05-02 14:28
    GalacticCowboy:
    s/Trent/Steve/

    Fixed that for ya.
    Same Mike/Michael and Trent as http://thedailywtf.com/Articles/Feng-Shui.aspx from the sound of it.
  • the guy behind you 2011-05-02 14:29
    fritters:
    Mr. Cranky Language Person:
    "Poring through the code"

    Thanks for getting that right.


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

    As in, gasoline.


    petrol?
  • frits 2011-05-02 14:40
    Pedantic CBE:
    C-Octothorpe:

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

    Well, I can see where that idea is coming from.

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

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

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

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

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


    OK. Cool. So which pattern do you use?
    On Error Resume Next

    or

    try
    {
    //Do stuff
    }
    catch(Exception swallowAll)
    {
    //Gulp! Bellllllllllch!
    }


  • hoodaticus 2011-05-02 14:42
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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

    It's perfectly valid in some situations. Like adding non-unique entries to a hashtable to get the unique exemplars, for hashtables that do not have a ContainsKey method.
  • jmucchiello 2011-05-02 14:44
    blah:
    TRWTF is not performing a diff. Presumably TRRWTF is no source control.

    This, and the lack of source control is almost a given.
  • C-Octothorpe 2011-05-02 14:47
    Pedantic CBE:
    C-Octothorpe:

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

    Well, I can see where that idea is coming from.

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

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

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

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

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


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

    I can't tell you how many times I have seen exceptions "handled" only to come and severely bite the developers in the ass during a production issue. Anytime something goes wrong during a user transaction, you need to tell them that something bad happened. Unless of course the exception was logged, corrected and that you can guarantee that the correction succeeded and nothing was lost with no side effect, in other words, as if the original transaction occured without error. Then and only then should you not notify the user, IMO.
  • Michael 2011-05-02 14:50
    Jeff:
    DCRoss:
    Problem: Software is showing error messages to user while running.

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

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

    If they plug it back in, then you can shoot them.
  • Michael (really) 2011-05-02 14:51
    Zolcos:
    That was probably the right decision. It doesn't really fix anything, of course, but doing it the right way would just waste a lot more time. This way he can get to finishing the rewrite.
    WC:
    At some point, you've got 'new' and 'old' backwards. I suspect Trent implemented it in the old version, and the submitter implemented it in the new version.

    I get the feeling that both the new and old versions were 'old' and not part of his rewrite


    That is correct...the 'new' one was a reskinning of the old software, but with all the same code. The future rewrite was actually in Delphi.
  • C-Octothorpe 2011-05-02 14:53
    Michael:
    Jeff:
    DCRoss:
    Problem: Software is showing error messages to user while running.

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

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

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


    No. You fray the wires so that they become ground when they try to plug it in again.
  • Nagesh 2011-05-02 14:58
    Al Jaseera:
    It is good thing Vista fix was implemented on DNA testing algorithm.

    You have made my day!!!! May my idol still be living!?!?!?!
  • Michael (really) 2011-05-02 15:02
    DaveK:
    GalacticCowboy:
    s/Trent/Steve/

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


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

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

    Trust me, lack of source control was the LEAST of their problems.
  • Peter 2011-05-02 15:05
    C-Octothorpe:
    Michael:
    Jeff:
    Shoot user?
    I see no reason to be so harsh. Just unplug their monitor.

    If they plug it back in, then you can shoot them.
    No. You fray the wires so that they become ground when they try to plug it in again.
    "Ground" as in "ground beef"?
  • BentFranklin 2011-05-02 15:08
    On Error Update Resume
  • Silfax 2011-05-02 15:10
    DCRoss:
    Problem: Software is showing error messages to user while running.

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

    Fix: Obvious.


    Would that be the "two fingered eyeball poke" or routing all error messages to /dev/null ?
  • Rootbeer 2011-05-02 15:30
    After 10 minutes of staring at the code, I just happened to glance up at the very top


    What the...? Did this happen before the invention of 'diff'?
  • drusi 2011-05-02 15:33
    Fact Checker:
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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



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

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


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


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

    Huh, apparently this is the second time I've had "modo" as my captcha.
  • Anon 2011-05-02 15:49
    Wasn't he living in Pakistan?

    I though Indians hated Pakistanis.

    Why would he be your idol?
  • Nagesh 2011-05-02 15:51
    PedanticCurmudgeon:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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

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

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


    Lot of childs in my class walk to school with no shoes. So no big deal. I was lucky to get auto.
  • laoreet 2011-05-02 15:58
    Fact Checker:
    Niten:
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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



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

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


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


    F U
  • Craig 2011-05-02 15:58
    I figured that maybe The Vista Fix was that the software uninstalled Vista and installed Windows XP.
  • Jaime 2011-05-02 16:00
    Nagesh:
    I did one class for VB6 that I ashamed to mention

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

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

    On a related note, occasionally my workstation at work gets into a state where all window creation fails. It's interesting to see how many applications don't check to see if CreateWindow returns a valid handle.
  • laoreet 2011-05-02 16:00
    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.
  • Some damn Yank 2011-05-02 16:09
    the guy behind you:
    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?
    To Brits, yes. In America we make lots of stuff from petroleum, not just gasoline, so "petrol" isn't specific enough for us. You Brits should understand this - you're BP crew gave us petrolated shrimp, petrolated beaches, petrolated turtles, petrolated dolphins...

    "ingenium" - readers of the Daily WTF are members of the ingenium.
  • Nagesh 2011-05-02 16:13
    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.

  • C-Octothorpe 2011-05-02 16:20
    laoreet:
    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.


    My god, with an eloquent response like that, we should obviously listen to you! Why don't you enlighten us all with the Right Way (TM) professor? I mean, clearly my years of experience cowers next to the intellectual prowess of someone who can only muster "I don't think"...

    It is you who should try again.
  • Gunslinger 2011-05-02 16:29
    Bryan the K:
    The real WTF is support for Vista? Right??


    Yes.
  • Gunslinger 2011-05-02 16:31
    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.


    Your instructor is wrong. There are certain conditions when you do want to do that.
  • C-Octothorpe 2011-05-02 16:31
    Craig:
    I figured that maybe The Vista Fix was that the software uninstalled Vista and installed Windows XP.


    Win.
  • Gunslinger 2011-05-02 16:32
    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?
  • Abso 2011-05-02 16:37
    Jaime:
    Nagesh:
    (trolling)
    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.

    It's almost like C and VB are two very different languages with different purposes.
  • Gunslinger 2011-05-02 16:37
    Michael (really):
    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.


    I agree, moving to Delphi is a much bigger problem than lack of source control.
  • Gunslinger 2011-05-02 16:39
    Craig:
    I figured that maybe The Vista Fix was that the software uninstalled Vista and installed Windows XP.


    That wouldn't be a WTF.
  • socknet 2011-05-02 16:49
    Rootbeer:
    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'?


    if a lot of code has changed in the file, then even with diff it may well take 10+ minutes to find which particular change is responsible.
  • Bob 2011-05-02 16:57
    Name me any programmer and I will show bugs in their code.
  • Yoda 2011-05-02 17:07
    Matthew Vines:
    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.


    Show bugs in their code I will if 4 programmers you name.
  • some dude 2011-05-02 17:24
    Jo Poser:
    "Poring"? Was it stinky or filmy?

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

    um. http://www.merriam-webster.com/dictionary/poring
  • Matt Westwood 2011-05-02 17:24
    Something like this bit us on the ankles recently. Our in-house signature app uses a 3rd-party piece of s...oftware called "lex" or something which makes some stuff easier, apparently.

    We recently upgraded to a new version of our in-house app. Ran it, it exited immediately (within the first few seconds). No error messages, no logs, no nothing to help us. Embarrassing as we were on the client's site at the time. Back in the office the software dev guys pondered it, then suggested we install a version of lex.jar from a few versions previous. This we did. Excellent - it sent a message to the log we'd been expecting to see something in to the effect that the jre was off kilter - and we could work out what had gone wrong from there.

    The WTF, of course, is that this later version of lex.jar no longer writes out its helpful stack traces to the logger. We know now to include "lex.jar_old" to our environment so we can swap it in as needs be when the s...oftware hits the fan again.

    Come on, say it, "the real WTF is using java". Sorry, but there we are, that's what we use, it's what I do to make money.
  • Matt Westwood 2011-05-02 17:26
    Some damn Yank:
    the guy behind you:
    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?
    To Brits, yes. In America we make lots of stuff from petroleum, not just gasoline, so "petrol" isn't specific enough for us. You Brits should understand this - you're BP crew gave us petrolated shrimp, petrolated beaches, petrolated turtles, petrolated dolphins...

    "ingenium" - readers of the Daily WTF are members of the ingenium.


    Oh we did, we did. Mind, the only thing British about BP is the name, we sold the company to the US a long time ago. But why should we care? It's not our beaches.
  • Nagesh 2011-05-02 17:27
    Yoda:
    Matthew Vines:
    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.


    Show bugs in their code I will if 4 programmers you name.


    you are making use of even poorer gramer than I am.
  • Nagesh 2011-05-02 17:28
    Matt Westwood:
    Something like this bit us on the ankles recently. Our in-house signature app uses a 3rd-party piece of s...oftware called "lex" or something which makes some stuff easier, apparently.

    We recently upgraded to a new version of our in-house app. Ran it, it exited immediately (within the first few seconds). No error messages, no logs, no nothing to help us. Embarrassing as we were on the client's site at the time. Back in the office the software dev guys pondered it, then suggested we install a version of lex.jar from a few versions previous. This we did. Excellent - it sent a message to the log we'd been expecting to see something in to the effect that the jre was off kilter - and we could work out what had gone wrong from there.

    The WTF, of course, is that this later version of lex.jar no longer writes out its helpful stack traces to the logger. We know now to include "lex.jar_old" to our environment so we can swap it in as needs be when the s...oftware hits the fan again.

    Come on, say it, "the real WTF is using java". Sorry, but there we are, that's what we use, it's what I do to make money.


    Sorry,but java's superiority is unmatched and style is also good.
  • Nagesh 2011-05-02 17:29
    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?


    He is looking for starting flaming war.
  • Matt 2011-05-02 17:31
    With out project, it takes "The Vista Fix" a step further. There is a requirement that every user interaction, MUST be enclosed in a try/catch block that dutifly hides all errors from ever being shown to the user. We instead log the error to an internal table. Never mind that no one ever looks at the table. What caused the error makes no difference - corrupt data? Just trap and log it - then dutifly ignore it. We're not talking about a few error per week - we're talking several thousand a day. The end user must never be allowed to know that an error occurred. The end result is management is now entirely convinced that everything is working just fine. The fact that wee lose data every now and then is consistently blamed on applications that have been in place and operational without any issues for many years.
  • Jaime 2011-05-02 17:34
    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.
  • Simon 2011-05-02 17:36
    Gunslinger:
    Your facts and logic are flawed. A person who writes good code will suddenly write bad code just because they get a degree?


    No, but *everyone* writes bad code. They may think it's good code at the time, but come back to it in a year's time, and they may think differently...
  • Jaime 2011-05-02 17:37
    Abso:
    Jaime:
    Nagesh:
    (trolling)
    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.

    It's almost like C and VB are two very different languages with different purposes.
    ... and apparently held to two very different standards. My comment was directed at the general attitude of considering everything that VB does to be bad, while simultaneously considering the same thing good in C.
  • Matt Westwood 2011-05-02 17:39
    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.
  • ObiWayneKenobi 2011-05-02 17:39
    Ah,
    On Error Resume Next
    , the bane of competent programmers everywhere. I have nightmares of slogging through an absolute cesspit of Classic ASP w/VBScript where every one of the 1000+ pages had that blasphemy plastered across the top, allowing the "senior developer" to merrily hack his way through trial and error. Try something, whoops that didn't output, let's try something else... viola, instant application! Many cases removing said blasphemy would cause the page to stop functioning because there were several cases where the "senior developer" had been calling methods on objects before the object was actually instantiated. I still have nightmares thinking of that code because trying to fix it (not even rewrite the slop) would have taken, I estimated, about 3 years.
  • Matt Westwood 2011-05-02 17:41
    Nagesh:
    Matt Westwood:
    Something like this bit us on the ankles recently. Our in-house signature app uses a 3rd-party piece of s...oftware called "lex" or something which makes some stuff easier, apparently.

    We recently upgraded to a new version of our in-house app. Ran it, it exited immediately (within the first few seconds). No error messages, no logs, no nothing to help us. Embarrassing as we were on the client's site at the time. Back in the office the software dev guys pondered it, then suggested we install a version of lex.jar from a few versions previous. This we did. Excellent - it sent a message to the log we'd been expecting to see something in to the effect that the jre was off kilter - and we could work out what had gone wrong from there.

    The WTF, of course, is that this later version of lex.jar no longer writes out its helpful stack traces to the logger. We know now to include "lex.jar_old" to our environment so we can swap it in as needs be when the s...oftware hits the fan again.

    Come on, say it, "the real WTF is using java". Sorry, but there we are, that's what we use, it's what I do to make money.


    Sorry,but java's superiority is unmatched and style is also good.


    Indeed. I love java, despite its perceived flaws. Never got on with C. Ho hum.
  • Matt Westwood 2011-05-02 17:42
    ObiWayneKenobi:
    Ah,
    On Error Resume Next
    , the bane of competent programmers everywhere. I have nightmares of slogging through an absolute cesspit of Classic ASP w/VBScript where every one of the 1000+ pages had that blasphemy plastered across the top, allowing the "senior developer" to merrily hack his way through trial and error. Try something, whoops that didn't output, let's try something else... viola, instant application! Many cases removing said blasphemy would cause the page to stop functioning because there were several cases where the "senior developer" had been calling methods on objects before the object was actually instantiated. I still have nightmares thinking of that code because trying to fix it (not even rewrite the slop) would have taken, I estimated, about 3 years.


    "... viola, instant application!..."

    Another one for the orchestra pit, Igor ...

    http://en.wiktionary.org/wiki/voil%C3%A0

    now go and learn it.
  • topspin 2011-05-02 17:43
    Matthew Vines:
    Nagesh:
    Niten:

    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.


    Don Knuth?

    Need to think of 3 others, though.
  • Optimus Dime 2011-05-02 17:43
    Matt:
    With out project, it takes "The Vista Fix" a step further. There is a requirement that every user interaction, MUST be enclosed in a try/catch block that dutifly hides all errors from ever being shown to the user. We instead log the error to an internal table. Never mind that no one ever looks at the table. What caused the error makes no difference - corrupt data? Just trap and log it - then dutifly ignore it. We're not talking about a few error per week - we're talking several thousand a day. The end user must never be allowed to know that an error occurred. The end result is management is now entirely convinced that everything is working just fine. The fact that wee lose data every now and then is consistently blamed on applications that have been in place and operational without any issues for many years.

    I think I work where you do...

    /captcha: minim
    ...um
  • ObiWayneKenobi 2011-05-02 17:47
    Matt Westwood:

    "... viola, instant application!..."

    Another one for the orchestra pit, Igor ...

    http://en.wiktionary.org/wiki/voil%C3%A0

    now go and learn it.


    Not the Orchestra Pit! Anything but that! I'll take On Error Resume Next over the Orchestra Pit!
  • Chris 2011-05-02 18:23
    Craig:
    I figured that maybe The Vista Fix was that the software uninstalled Vista and installed Windows XP.

    Or preferably 2000.
  • Abso 2011-05-02 18:40
    Jaime:
    Abso:
    Jaime:
    Nagesh:
    (trolling)
    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.

    It's almost like C and VB are two very different languages with different purposes.
    ... and apparently held to two very different standards. My comment was directed at the general attitude of considering everything that VB does to be bad, while simultaneously considering the same thing good in C.
    Well, I haven't much experience with VB, but it seems the problem here isn't something that VB does, it's the disabling of something VB does (ie fancy error handling).

    As for the pattern this would force being considered good in C: There is a difference between disabling a tool and not having it in the first place.

    Plus, with the code actually under discussion, it seems doubtful that error codes were being checked after every call (or ever). (Not that that never happens in C.)
  • Rob 2011-05-02 19:16
    Jaime:
    Nagesh:

    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.


    setjmp / longjmp. So yeah, it does.


  • Gary Olson 2011-05-02 19:33
    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?


    Tequila shooters.
    Then the user can't see the errors, the user can't understand the data, and the inverse function of the tequila infusion will create a self correcting system.

    Get off my barstool, kid.
  • hoodaticus 2011-05-02 19:33
    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 - we haven't yet hired a guy with a CS degree. I will post a comment here once one of them passes the fizzbuzz test (which I am hoping will be this week. I've got a candidate I really like, and he has a masters).
  • Derek 2011-05-02 20:24
    I've used this in some VBS scripts before. I added my own error handler such as "if Err.Number <> 0 Then" and added error handling code. Of course, in VB6 you can have it go to a line or label.
  • Jaime 2011-05-02 21:05
    Abso:
    Jaime:
    Abso:
    Jaime:
    Nagesh:
    (trolling)
    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.

    It's almost like C and VB are two very different languages with different purposes.
    ... and apparently held to two very different standards. My comment was directed at the general attitude of considering everything that VB does to be bad, while simultaneously considering the same thing good in C.
    Well, I haven't much experience with VB, but it seems the problem here isn't something that VB does, it's the disabling of something VB does (ie fancy error handling).

    As for the pattern this would force being considered good in C: There is a difference between disabling a tool and not having it in the first place.

    Plus, with the code actually under discussion, it seems doubtful that error codes were being checked after every call (or ever). (Not that that never happens in C.)
    Fancy error handling? The extent of VB6 error handling fanciness is to jump to a line label in the same procedure. If no error handler is defined, then it shows the stock error message and quits the application. I'd hardly call that fancy or even desirable. You get forced to choose between two hacks -- either put boiler plate code in every procedure ever written, or handle errors C-style. Going with C-style error handling is no worse than the alternative. On Error Resume Next got a bad reputation because a lot of programmers didn't check their error codes.

    The double-standard is that when VB programmers forget to check their error codes, VB is a bad tool. When C programmers forget, C remains blame-free.
  • ObiWayneKenobi 2011-05-02 21:39
    Derek:
    I've used this in some VBS scripts before. I added my own error handler such as "if Err.Number <> 0 Then" and added error handling code. Of course, in VB6 you can have it go to a line or label.


    Well, that's the proper way to use it. But most people who use it just plaster it at the top of every code file and then don't even bother to check any errors, they just hack away.
  • moz 2011-05-02 21:41
    Jaime:
    The double-standard is that when VB programmers forget to check their error codes, VB is a bad tool. When C programmers forget, C remains blame-free.

    You sound like someone who has never tried to program in C. If you get chance, find a C compiler and experiment with the following code:
    #include <stdio.h>
    
    int main() {return puts(gets(0));}

    Before you do, I should just add:

    This code is provided "as is" without warranty of any kind, either expressed or implied. In particular, I disclaim all liability for any direct, indirect or consequential loss, damage, injury or death resulting from its use.
  • no-one 2011-05-02 21:53
    Jaime:
    Abso:
    Jaime:
    Abso:
    Jaime:
    Nagesh:
    (trolling)
    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.

    It's almost like C and VB are two very different languages with different purposes.
    ... and apparently held to two very different standards. My comment was directed at the general attitude of considering everything that VB does to be bad, while simultaneously considering the same thing good in C.
    Well, I haven't much experience with VB, but it seems the problem here isn't something that VB does, it's the disabling of something VB does (ie fancy error handling).

    As for the pattern this would force being considered good in C: There is a difference between disabling a tool and not having it in the first place.

    Plus, with the code actually under discussion, it seems doubtful that error codes were being checked after every call (or ever). (Not that that never happens in C.)
    Fancy error handling? The extent of VB6 error handling fanciness is to jump to a line label in the same procedure. If no error handler is defined, then it shows the stock error message and quits the application. I'd hardly call that fancy or even desirable. You get forced to choose between two hacks -- either put boiler plate code in every procedure ever written, or handle errors C-style. Going with C-style error handling is no worse than the alternative. On Error Resume Next got a bad reputation because a lot of programmers didn't check their error codes.

    The double-standard is that when VB programmers forget to check their error codes, VB is a bad tool. When C programmers forget, C remains blame-free.


    Incorrect. VB6 exceptions will bubble up the call stack looking for an active handler. Only if the exception reaches the top of the stack, or a break in it, without being handled will the application quit.
  • DaveK 2011-05-02 22:25
    topspin:
    Matthew Vines:
    Nagesh:
    Niten:

    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.


    Don Knuth?

    Don Knuth himself fully expects his code to have bugs in it. If you go to his homepage you can even download the errata.
  • Jaime 2011-05-02 23:31
    no-one:
    Jaime:
    Abso:
    Jaime:
    Abso:
    Jaime:
    Nagesh:
    (trolling)
    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.

    It's almost like C and VB are two very different languages with different purposes.
    ... and apparently held to two very different standards. My comment was directed at the general attitude of considering everything that VB does to be bad, while simultaneously considering the same thing good in C.
    Well, I haven't much experience with VB, but it seems the problem here isn't something that VB does, it's the disabling of something VB does (ie fancy error handling).

    As for the pattern this would force being considered good in C: There is a difference between disabling a tool and not having it in the first place.

    Plus, with the code actually under discussion, it seems doubtful that error codes were being checked after every call (or ever). (Not that that never happens in C.)
    Fancy error handling? The extent of VB6 error handling fanciness is to jump to a line label in the same procedure. If no error handler is defined, then it shows the stock error message and quits the application. I'd hardly call that fancy or even desirable. You get forced to choose between two hacks -- either put boiler plate code in every procedure ever written, or handle errors C-style. Going with C-style error handling is no worse than the alternative. On Error Resume Next got a bad reputation because a lot of programmers didn't check their error codes.

    The double-standard is that when VB programmers forget to check their error codes, VB is a bad tool. When C programmers forget, C remains blame-free.


    Incorrect. VB6 exceptions will bubble up the call stack looking for an active handler. Only if the exception reaches the top of the stack, or a break in it, without being handled will the application quit.
    Explain where I am incorrect. You say "Only if the exception reaches the top of the stack, or a break in it, without being handled" and I say "If no error handler is defined" -- same thing. I don't recall saying that it won't bubble up and I don't see any reference to "no error handler" being limited to the current function. You still need to define a handler at the proper level because the Resume Next statement is scoped to the function it is issued in.
  • Jaime 2011-05-02 23:54
    moz:
    Jaime:
    The double-standard is that when VB programmers forget to check their error codes, VB is a bad tool. When C programmers forget, C remains blame-free.

    You sound like someone who has never tried to program in C. If you get chance, find a C compiler and experiment with the following code:
    #include <stdio.h>
    
    int main() {return puts(gets(0));}

    Before you do, I should just add:

    This code is provided "as is" without warranty of any kind, either expressed or implied. In particular, I disclaim all liability for any direct, indirect or consequential loss, damage, injury or death resulting from its use.
    I never said that C can't be used for evil or that the error handling conventions in C are sane. I said that the code you posted would be blamed on the programmer, not the language. However, any bug in VB code is usually used as a platform to say "The real WTF is VB".

    BTW, I'm still trying to figure out your rationale for saying that I've never programmed in C. I can see the guy who mentioned longjmp saying it, because he actually noted a feature of the C Standard Library that I strategically ignored (it's a library function, not a language feature). However your argument seems to be: You mentioned that C programmers sometimes forget to check the return code of functions, here's some C code that doesn't check the return codes of anything and recklessly uses a zero pointer, ha - got you.
  • No, Not That Guy 2011-05-03 00:06
    hoodaticus:
    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 - we haven't yet hired a guy with a CS degree. I will post a comment here once one of them passes the fizzbuzz test (which I am hoping will be this week. I've got a candidate I really like, and he has a masters).


    Lest software developers feel unique, this is also true for hardware technicians. Can't count the number of times I've had to show someone with a fresh cert or degree how to use a voltmeter or even something as painfully simple as a magnetizer.
  • Matt Westwood 2011-05-03 01:17
    No, Not That Guy:
    hoodaticus:
    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 - we haven't yet hired a guy with a CS degree. I will post a comment here once one of them passes the fizzbuzz test (which I am hoping will be this week. I've got a candidate I really like, and he has a masters).


    Lest software developers feel unique, this is also true for hardware technicians. Can't count the number of times I've had to show someone with a fresh cert or degree how to use a voltmeter or even something as painfully simple as a magnetizer.


    Good call. Are "sandwich courses" still on offer to students? Industrially-sponsored degree courses in which academic terms are alternated with periods of direct industry apprenticeships. You end up with a generation of electronic engineering graduates who know how to use a soldering iron and even (in extreme cases) welding equipment. Happy days.
  • bjolling 2011-05-03 03:17
    hoodaticus:
    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.

    or in

    On Error Goto Errorhandler
    ' Do stuff
    Goto End

    Errorhandler:
    On Error Resume Next
    ' Log error

    End:
    ' Do Clean up
  • Eskil 2011-05-03 03:23
    There were tons and tons and more tons of those in an order system that I maintained at a previous employer. They would obvioulsy produce all kinds of seemingly completely random results, and they were a complete pain to try and fix

    We kept finding bugs that had been there since the application was brand new, but since the application just resumed the next line when the Sub crashed, they had never been noticed.

    I'm no longer with that company.
  • WhoCare 2011-05-03 03:24
    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.


    You realized that CS degree are not the only one giving "structured thinking", or, for what it matters, programming lessons ?
  • illtiz 2011-05-03 03:37
    Matthew Vines:
    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.


    I demand this be turned blue, Alex.
  • Gunslinger 2011-05-03 03:37
    Chris:
    Craig:
    I figured that maybe The Vista Fix was that the software uninstalled Vista and installed Windows XP.

    Or preferably 2000.


    God, no. XP is vastly superior to 2000.
  • Darth Paul 2011-05-03 04:46
    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.
  • Marvin the Martian 2011-05-03 06:35
    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 07:26
    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.
  • OptionExplicit 2011-05-03 07:33
    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.
  • Arvind 2011-05-03 07:47
    Vista? Seriously? Why do you use Vista at work? Why do you use Vista at ANYTHING?
  • Nagesh 2011-05-03 08:07
    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!)
  • QJ 2011-05-03 08:18
    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 08:42
    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.
  • Nagesh 2011-05-03 08:50
    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 08:50
    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.
  • QJ 2011-05-03 08:53
    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?"
  • Anon 2011-05-03 08:57
    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?
  • Nagesh 2011-05-03 09:22
    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!
  • Todd Lewis 2011-05-03 09:24
    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 09:30
    [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.
  • socknet 2011-05-03 09:31
    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'
  • QJ 2011-05-03 09:43
    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.
  • C0ndom 2011-05-03 09:56
    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){}
  • CS 2011-05-03 09:59
    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.
  • Brahma 2011-05-03 10:08
    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!
  • QJ 2011-05-03 10:09
    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 10:17
    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(...){}


  • C-Octothorpe 2011-05-03 10:19
    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.
  • C-Octothorpe 2011-05-03 10:28
    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.
  • QJ 2011-05-03 10:37
    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 10:41
    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.
  • socknet 2011-05-03 10:45
    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.
  • C-Octothorpe 2011-05-03 10:55
    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?

    1) You try to save "report"
    2) Request posts to the server
    3) Passes validation, call service.Save(objectToSave)
    4) Server throws exception because the intertubes are clogged and can't reach the endpoint.
    5) [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.
  • QJ 2011-05-03 11:02
    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.
  • Star Fox 2011-05-03 11:03
    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?
  • socknet 2011-05-03 11:03
    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?

    1) You try to save "report"
    2) Request posts to the server
    3) Passes validation, call service.Save(objectToSave)
    4) Server throws exception because the intertubes are clogged and can't reach the endpoint.
    5) [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 11:04
    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");

  • QJ 2011-05-03 11:05
    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 ...
  • C-Octothorpe 2011-05-03 11:06
    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.
  • The Corrector 2011-05-03 11:11
    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 11:12
    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 11:12
    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!
  • socknet 2011-05-03 11:14
    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.
  • C-Octothorpe 2011-05-03 11:15
    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...
  • socknet 2011-05-03 11:19
    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 11:20
    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
  • QJ 2011-05-03 11:24
    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.
  • C-Octothorpe 2011-05-03 11:25
    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 11:28
    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.
  • QJ 2011-05-03 11:28
    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.
  • Nagesh 2011-05-03 11:30
    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.
  • frits 2011-05-03 11:35
    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?
  • No-Fail 2011-05-03 11:35
    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.
  • frits 2011-05-03 11:35
    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?



    Speaking of Error'd, why are they using a comma for an apostrophe?
  • socknet 2011-05-03 11:36
    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)
  • 8% Denisovan 2011-05-03 11:38
    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.


    Oh? http://translate.google.com/#de|sv|Matterhorn

    Google translate is not spam askimet
  • Nagesh 2011-05-03 11:40
    Brahma:
    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!


    Make fun of gods and gods will truble you!
  • C-Octothorpe 2011-05-03 11:49
    Nagesh:
    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.


    People like you? You mean american douchebag pretending to be indian developer?
  • James Galway 2011-05-03 11:55
    socknet:


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





  • socknet 2011-05-03 12:00
    James Galway:
    socknet:


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








    yes - someone did something stupid. Although from memory this is actually somewhat valid (as I recall, a more meaningful message would have been "Could not create additional/intended dialog box". Anyway, it doesn't actually have any relevance to what you quoted.

    Why shouldn't this exception (assuming it was even an exception) be caught and handled?
  • C-Octothorpe 2011-05-03 12:16
    socknet:
    James Galway:
    socknet:


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








    yes - someone did something stupid. Although from memory this is actually somewhat valid (as I recall, a more meaningful message would have been "Could not create additional/intended dialog box". Anyway, it doesn't actually have any relevance to what you quoted.

    Why shouldn't this exception (assuming it was even an exception) be caught and handled?

    SELECT * FROM USERS WHERE SENSE_OF_HUMOR > 0
    
    (0 row(s) affected)
  • VB6slave 2011-05-03 12:29
    An exception which shouldn't be handled....

    Here's one I DO use "On Error Resume Next" for:

    ...
    txtSomeTextBox.SetFocus
    ...

    Setting the focus isn't critical, only a nicety. The fact that VB6 blows up with an Illegal function call if it can't set the focus (perhaps its on a hidden window) is beyond me.

    I've had to write so much VB6 code I broke down on the 3rd day of my previous job and wrote a tool to automate writing of error handlers for VB 5/6. My code is slathered in error handlers, most of which DO report errors to the user, and the location thisform->thisfunction, etc, and also writes to an error log file. Errors in the applications I write *shouldn't* happen. I want the user to call for help if one happens. My favorite type of "user error" just happened *again*.

    My (inherited) application currently uses Access (yes yes, double evil, VB6 and Access). Works great for 99.99% of people. Small app, small DB, not much going on, so using some fancy DB for it is asking for more trouble than it's worth (I've been tempted to go to flat files, it's so small).

    Anyways, user calls support for help, can't run reports, says file already open or DB already locked by another user... on a single user system. User swears up and down this is the first time he's had trouble. Finally, I ask for the error log... very first error is from the previous friday, this was a monday.... and what did it say? "Unrecognized database format.". But since it only happened when he logged off the program, it didn't occur to him that this might be a BAD thing.

    So I got to spend several hours manually copying records out of his database to a new one since Access and all its tools couldn't repair it. And he got to spend quite a few hundred dollars for me to do it. (of course he didn't have backups, don't even THINK about asking that).

    Error logs, how I love thee....
  • socknet 2011-05-03 12:34
    C-Octothorpe:
    socknet:
    James Galway:
    socknet:


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








    yes - someone did something stupid. Although from memory this is actually somewhat valid (as I recall, a more meaningful message would have been "Could not create additional/intended dialog box". Anyway, it doesn't actually have any relevance to what you quoted.

    Why shouldn't this exception (assuming it was even an exception) be caught and handled?

    SELECT * FROM USERS WHERE SENSE_OF_HUMOR > 0
    
    (0 row(s) affected)



    sorry - I didn't realise that I was obligated to laugh at something of no relevance. What did you want me to say..

    "LOL, OMG, ROFFLE, THAT IS SO FUNNY BECAUSE IT SAYS IT CANNOT CREATE A DIALOG BOX, BUT IT DID!!! OMG... GET IT??"

    Post something which is both relevant and amusing, and I'll give it the credit it deserves.
  • socknet 2011-05-03 12:37
    VB6slave:
    An exception which shouldn't be handled....

    Here's one I DO use "On Error Resume Next" for:
    (snip)



    You do realise that by putting "On Error Resume Next" you are actually handling the error, right?
  • Yazeran 2011-05-03 12:43
    Jaime:
    moz:

    You sound like someone who has never tried to program in C. If you get chance, find a C compiler and experiment with the following code:
    #include <stdio.h>
    
    int main() {return puts(gets(0));}

    Before you do, I should just add:

    This code is provided "as is" without warranty of any kind, either expressed or implied. In particular, I disclaim all liability for any direct, indirect or consequential loss, damage, injury or death resulting from its use.
    I never said that C can't be used for evil or that the error handling conventions in C are sane. I said that the code you posted would be blamed on the programmer, not the language. However, any bug in VB code is usually used as a platform to say "The real WTF is VB".

    BTW, I'm still trying to figure out your rationale for saying that I've never programmed in C. I can see the guy who mentioned longjmp saying it, because he actually noted a feature of the C Standard Library that I strategically ignored (it's a library function, not a language feature). However your argument seems to be: You mentioned that C programmers sometimes forget to check the return code of functions, here's some C code that doesn't check the return codes of anything and recklessly uses a zero pointer, ha - got you.


    I actually just tried that code, the output from gcc was actually quite funny:

    $ gcc -lm test.c
    /tmp/ccKPC5nw.o: In function `main':
    test.c:(.text+0x11): warning: the `gets' function is dangerous and should not be used.

    And of cause te resulting executable segfaulted.. :-)
  • Nagesh 2011-05-03 13:24
    VB6slave:
    An exception which shouldn't be handled....

    Here's one I DO use "On Error Resume Next" for:

    ...
    txtSomeTextBox.SetFocus
    ...

    Setting the focus isn't critical, only a nicety. The fact that VB6 blows up with an Illegal function call if it can't set the focus (perhaps its on a hidden window) is beyond me.

    I've had to write so much VB6 code I broke down on the 3rd day of my previous job and wrote a tool to automate writing of error handlers for VB 5/6. My code is slathered in error handlers, most of which DO report errors to the user, and the location thisform->thisfunction, etc, and also writes to an error log file. Errors in the applications I write *shouldn't* happen. I want the user to call for help if one happens. My favorite type of "user error" just happened *again*.

    My (inherited) application currently uses Access (yes yes, double evil, VB6 and Access). Works great for 99.99% of people. Small app, small DB, not much going on, so using some fancy DB for it is asking for more trouble than it's worth (I've been tempted to go to flat files, it's so small).

    Anyways, user calls support for help, can't run reports, says file already open or DB already locked by another user... on a single user system. User swears up and down this is the first time he's had trouble. Finally, I ask for the error log... very first error is from the previous friday, this was a monday.... and what did it say? "Unrecognized database format.". But since it only happened when he logged off the program, it didn't occur to him that this might be a BAD thing.

    So I got to spend several hours manually copying records out of his database to a new one since Access and all its tools couldn't repair it. And he got to spend quite a few hundred dollars for me to do it. (of course he didn't have backups, don't even THINK about asking that).

    Error logs, how I love thee....


    What? You did not have auto-backup system?
  • Grammer Nazi 2011-05-03 13:24
    socknet:
    VB6slave:
    An exception which shouldn't be handled....

    Here's one I DO use "On Error Resume Next" for:
    (snip)



    You do realize that by putting "On Error Resume Next" you are actually handling the error, right?

    FTFY. Man, it drives me nuts when folks make fun of the way some people write COMPUTER languages whilst butchering one that they're supposed to write natively.
  • VB6slave 2011-05-03 13:25
    I don't consider ignoring it to be "handling" it. I write error handlers to handle errors.... ;)

  • HellKarnassus 2011-05-03 13:29
    C-Octothorpe:
    socknet:
    James Galway:
    socknet:


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








    yes - someone did something stupid. Although from memory this is actually somewhat valid (as I recall, a more meaningful message would have been "Could not create additional/intended dialog box". Anyway, it doesn't actually have any relevance to what you quoted.

    Why shouldn't this exception (assuming it was even an exception) be caught and handled?

    SELECT * FROM USERS WHERE SENSE_OF_HUMOR > 0
    
    System.Data.SqlClient.SqlException was unhandled
    Message="Invalid column name 'SENSE_OF_HUMOR'."
    Source=".Net SqlClient Data Provider"
    ErrorCode=-2146232060

    FTFY
  • Ford Engineer 2011-05-03 13:29
    Nagesh:

    What? You did not have auto-backup system?

    This is actually a fairly difficult problem to handle with the complexity of modern transmissions. It does remind me of the classic example of "over-engineering" where Chrysler spent millions of dollars over the course of a decade designing a motor which provided identical capabilities in forward and reverse, never realizing that people typically don't need to have the ability to drive 60mph in reverse.
  • VB6slave 2011-05-03 13:32
    Heh. We all know the capabilities of the average computer user.

    I've actually had the "CD-rom tray as coffee cup holder" and the "insert CD-ROM into 5.25" drive (and wonder why it comes back out scratched)" customer support nightmares...

  • Uh... 2011-05-03 13:34
    Grammer Nazi:
    socknet:
    VB6slave:
    An exception which shouldn't be handled....

    Here's one I DO use "On Error Resume Next" for:
    (snip)



    You do realize that by putting "On Error Resume Next" you are actually handling the error, right?

    FTFY. Man, it drives me nuts when folks make fun of the way some people write COMPUTER languages whilst butchering one that they're supposed to write natively.

    Your kidding, right?
  • Childish 2011-05-03 13:40
    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.


    C has UNIX signals, which are essentially exceptions. For example, signal 13, SIGBUS, is like IOException. "Segmentation fault", SIGBUS, is a NullPointerException.
  • AndyC 2011-05-03 13:48
    registry cleaning


    That's TRWTF right? Or is it just people who use "registry cleaners?"
  • Abso 2011-05-03 13:48
    Uh...:
    Grammer Nazi:
    socknet:
    VB6slave:
    An exception which shouldn't be handled....

    Here's one I DO use "On Error Resume Next" for:
    (snip)

    You do realize that by putting "On Error Resume Next" you are actually handling the error, right?

    FTFY. Man, it drives me nuts when folks make fun of the way some people write COMPUTER languages whilst butchering one that they're supposed to write natively.

    Your kidding, right?

    As everyone knows, the internet is only accessible from the United States of America. So it's entirely reasonable to reject British spellings.
  • Ilya Ehrenburg 2011-05-03 14:10
    Abso:

    As everyone knows, the internet is only accessible from the United States of America. So it's entirely reasonable to reject British spellings.

    Ah, nice. Where can I pick up my passport?
  • Rob 2011-05-03 15:56
    socknet:

    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.


    Stack corruption or heap management block corruption. Any attempt to handle will allow an exploit.
  • mh 2011-05-03 18:47
    The real vista fix:

    format c:
  • moz 2011-05-03 19:52
    Jaime:
    BTW, I'm still trying to figure out your rationale for saying that I've never programmed in C.

    Quite simply, I don't think anyone who has ever used VB6 and C for something more complex than "hello world" would ever confuse their error handling paradigms.

    My hope was that you would run that code and come across an error handling mechanism which is not similar to "on error resume next". Just out of curiosity, could you please tell me what you think the code I posted actually does?
    Jaime:
    However your argument seems to be: You mentioned that C programmers sometimes forget to check the return code of functions, here's some C code that doesn't check the return codes of anything and recklessly uses a zero pointer, ha - got you.
    No, the return codes are neither here nor there. The following is just as bad, even though it assiduously checks every return code it sees (I changed 0 into c just so that I can distinguish gets() failing from gets() succeeding). If you can't run it, please tell me what you think happens if the code encounters an error?
    #include <stdio.h>
    
    int main() {char c[8];
    if (!gets(c)) return 1;
    if (puts(c) == EOF) return 1;
    return 0;}

    Yazeran:
    I actually just tried that code, the output from gcc was actually quite funny:

    t$ gcc -lm test.c
    /tmp/ccKPC5nw.o: In function `main':
    test.c:(.text+0x11): warning: the `gets' function is dangerous and should not be used.

    They're quite right to say that. gets() is still in the standard, though, so it compiles perfectly well.
  • Arancaytar 2011-05-04 04:40
    On Error Resume Using Language That Is A Blight On Computing.
  • Nick J 2011-05-04 05:49
    The very fact that "on error resume next" is even allowed is itself a WTF. It might as well be called "crash blindly on and destroy all data".
    VB never has been and never will be a proper programming language.
  • Magnus 2011-05-04 07:50
    My best guess is that 'Trent' is an consultant from accenture. Because I have all the same feelings for the code that I got handover, that michael had about trents code, from consultants at accenture.
  • xyourfacekillerx 2011-05-04 13:55
    C-Octothorpe:
    laoreet:
    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.


    My god, with an eloquent response like that, we should obviously listen to you! Why don't you enlighten us all with the Right Way (TM) professor? I mean, clearly my years of experience cowers next to the intellectual prowess of someone who can only muster "I don't think"...

    It is you who should try again.


    You're right. TDWTF has never been the same since Fark culture infiltrated.
  • no-one 2011-05-04 15:24
    Jaime:
    no-one:
    Jaime:
    Abso:
    Jaime:
    Abso:
    Jaime:
    Nagesh:
    (trolling)
    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.

    It's almost like C and VB are two very different languages with different purposes.
    ... and apparently held to two very different standards. My comment was directed at the general attitude of considering everything that VB does to be bad, while simultaneously considering the same thing good in C.
    Well, I haven't much experience with VB, but it seems the problem here isn't something that VB does, it's the disabling of something VB does (ie fancy error handling).

    As for the pattern this would force being considered good in C: There is a difference between disabling a tool and not having it in the first place.

    Plus, with the code actually under discussion, it seems doubtful that error codes were being checked after every call (or ever). (Not that that never happens in C.)
    Fancy error handling? The extent of VB6 error handling fanciness is to jump to a line label in the same procedure. If no error handler is defined, then it shows the stock error message and quits the application. I'd hardly call that fancy or even desirable. You get forced to choose between two hacks -- either put boiler plate code in every procedure ever written, or handle errors C-style. Going with C-style error handling is no worse than the alternative. On Error Resume Next got a bad reputation because a lot of programmers didn't check their error codes.

    The double-standard is that when VB programmers forget to check their error codes, VB is a bad tool. When C programmers forget, C remains blamme-free.


    Incorrect. VB6 exceptions will bubble up the call stack looking for an active handler. Only if the exception reaches the top of the stack, or a break in it, without being handled will the application quit.
    Explain where I am incorrect. You say "Only if the exception reaches the top of the stack, or a break in it, without being handled" and I say "If no error handler is defined" -- same thing. I don't recall saying that it won't bubble up and I don't see any reference to "no error handler" being limited to the current function. You still need to define a handler at the proper level because the Resume Next statement is scoped to the function it is issued in.


    From the statement in bold, I assumed you were suggesting that every procedure required a handler because exceptions weren't able to leave the local scope.

    Given that you weren't, I'm confused why every procedure would need a handler. I would expect only to catch where appropriate. In some you'd even want to raise custom exceptions specifically for the benefit of callers.

    It falls a long way short of proper try/catch of course, but you can coerce useful protection out of it with careful use.
  • BrodeERTW 2011-05-04 16:07
    Matthew Vines:
    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.


    Me: Brodey.

    Code:

    int main(int argc, char **argv)
    {
    printf("Hello World.\n");
    return 0;
    }

    Result:
    No bugs. Eff off.
  • BrodeERTW 2011-05-04 16:13
    hoodaticus:
    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 - we haven't yet hired a guy with a CS degree. I will post a comment here once one of them passes the fizzbuzz test (which I am hoping will be this week. I've got a candidate I really like, and he has a masters).


    What's the job for?
  • Zebedee 2011-05-04 18:05
    You don't check the return code from printf. What if i redirect output to a read only file?
  • Rob 2011-05-04 19:09
    No function printf available. (you forgot the include)
    No entry point for a console app for Windows

  • runescape gold 2011-05-05 23:44
  • Chris 2011-05-06 11:48
    UGH! It's hard to think someone ever would use this line of code, but it's sadly true.

    I was recently tasked with rewriting several VBScripts into a C# executable. Unfortunately, I found "On Error Resume Next" all over the place. Thanks to this one-line-devil, it took me more than twice as long to figure out what the program "is supposed to do" VS "actually does".
  • Geoff 2011-05-06 23:17
    Matthew Vines:
    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.


    Linus Torvalds, Donald Knuth, Bill Gates, Mark Zuckerberg.
  • Andy 2011-05-09 17:23
    Waiting to see an analysis of (presumably proprietary) code by Microsoft, among others. Matthew, get on the horn.
  • e john 2011-05-09 22:16
    I don't like to handle exceptions. It gets my hands all icky.
  • Dan 2011-06-17 01:20
    CS programmers will make technically perfect code that doesn't work. Non-CS programmers tend to write sloppy code that somehow works.
    Put two in a room and you will usually get something pretty good or the CS guy doesn't make it out of the room.
  • asfddfsa 2011-06-27 02:11
    sadfdfs,perfect world,dsfdfaadfs,comprar gold pw,dsfadsfdsfa
  • Prism 2011-07-10 22:09
    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'


    Bubblesort is neat.
    But then again I enjoy that Zen moment when two pieces of bread come together to 'become' a sandwich. Ontology.

    Life is much more fascinating once you force yourself not to take it for granted.
  • He Can't Read Law 2011-09-20 10:55
    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.


    Epic fail.

    I would like you to debug failure at client sites due to unknown variables (another process is fudging with your files, webservice calls, etc.) without having an app terminate with an error.

    Or how about your client finds out months too late, that all the data he thought he was backing up to your cloud, didn't get there.

    If there is an exception, and it's one that halts progress, the app should terminate with a hard error.

    Living in a world without errors is a fantasy, unless you have a very simplistic program that doesn't work with files, webservices, databases, or any other methodology where data can be corrupted external to your app. I suppose a nice calculator app would work fine.