• 8% Denisovan (unregistered) in reply to QJ
    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

  • (cs) in reply to Brahma
    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 (unregistered) in reply to Nagesh
    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 (unregistered) in reply to socknet
    socknet:

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

    [image]
  • socknet (unregistered) in reply to James Galway
    James Galway:
    socknet:

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

    [image]

    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 (unregistered) in reply to socknet
    socknet:
    James Galway:
    socknet:

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

    [image]

    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 (unregistered) in reply to socknet

    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 (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    socknet:
    James Galway:
    socknet:

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

    [image]

    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 (unregistered) in reply to VB6slave
    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?

  • (cs) in reply to Jaime
    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: thegets' function is dangerous and should not be used.

    And of cause te resulting executable segfaulted.. :-)

  • (cs) in reply to VB6slave
    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 (unregistered) in reply to socknet
    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 (unregistered) in reply to socknet

    I don't consider ignoring it to be "handling" it. I write error handlers to handle errors.... ;)

  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    socknet:
    James Galway:
    socknet:

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

    [image]

    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 (unregistered) in reply to Nagesh
    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 (unregistered) in reply to Nagesh

    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... (unregistered) in reply to Grammer Nazi
    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 (unregistered) in reply to Jaime
    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 (unregistered)
    registry cleaning

    That's TRWTF right? Or is it just people who use "registry cleaners?"

  • Abso (unregistered) in reply to Uh...
    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.
  • (cs) in reply to Abso
    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 (unregistered) in reply to socknet
    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 (unregistered)

    The real vista fix:

    format c:
  • moz (unregistered) in reply to Jaime
    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: thegets' 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.

  • (cs)

    On Error Resume Using Language That Is A Blight On Computing.

  • Nick J (unregistered)

    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 (unregistered)

    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.

  • (cs) in reply to C-Octothorpe
    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 (unregistered) in reply to Jaime
    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 (unregistered) in reply to Matthew Vines
    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 (unregistered) in reply to hoodaticus
    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 (unregistered) in reply to BrodeERTW

    You don't check the return code from printf. What if i redirect output to a read only file?

  • Rob (unregistered) in reply to BrodeERTW

    No function printf available. (you forgot the include) No entry point for a console app for Windows

  • Chris (unregistered)

    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 (unregistered) in reply to Matthew Vines
    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 (unregistered) in reply to Geoff

    Waiting to see an analysis of (presumably proprietary) code by Microsoft, among others. Matthew, get on the horn.

  • e john (unregistered)

    I don't like to handle exceptions. It gets my hands all icky.

  • Dan (unregistered) in reply to Matthew Vines

    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.

  • Prism (unregistered) in reply to socknet
    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 (unregistered) in reply to Pedantic CBE
    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.

Leave a comment on “The Vista Fix”

Log In or post as a guest

Replying to comment #:

« Return to Article