• (cs) in reply to Kix

    !this.isFunny()

  • Jeff (unregistered) in reply to LordHunter317
    Anonymous:
    chrismcb:
    IF you don't do this, your program will crash. Letting your program crash is pretty scary and amatuerish. I would want to handle my errors, and not just crash whenever something goes wrong.
    No, it isn't.  In the face of many errors (and quite potentially the majority) it's the only sane behavior to take, because the error that occurs is inherently unrecoverable.

    And if you cannot recover and resume normal operation, then the only correct beavhior is to crash imediately, gracefully (meaning attempt to save work or whatever where possible), and with as much useful information as possible.


    That is like saying "When someone breaks into your house, the only correct behavior is to kill the burgler, but without harming him or hurting him if possible."   You are contradicting yourself.  I think we all understand (and agree with) your overall point, but using the word "crash" is wrong. 

  • Danh Dang (unregistered) in reply to Anonymous jr.

    Yeah, I agree.  This gotta be fake.  If a guy can use delegates and generics, he's not going to be writing that kind of code.

  • jespo (unregistered) in reply to Kix

    Im going to catch{} the guy who started all these bad puns

  • (cs) in reply to BlueEagle
    Anonymous:
    Defensive programming states that you should check if you can do something before you try to do it.


    That is not defensive enough.  Between your check that you can do some action and doing it, it may become impossible.

    User A checks if a file exists and can be opened.
    User B deletes the file (or changes the permissions).
    User A attempts to open the file.  BOOM!

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Manni
    Manni:

    One alternative is "On Error Goto", which is just frickin scary and amateurish to use. I want to handle my errors, not jump to a certain line in my code whenever something goes wrong.



    What do you think try/catch/throw is? 
  • LordHunter317 (unregistered) in reply to Jeff
    Anonymous:
    You are contradicting yourself.  I think we all understand (and agree with) your overall point, but using the word "crash" is wrong.
    No, I'm not.  Show me  a logical proof of how "abnormal program termination" also know as a "crash" is conflicting with saving a user's work before terminiation.

    Word does it, Visual Studio 2005 does it, so don't bother with that proof.  It would instantly be logically invalid due to proof by counterexample.


  • (cs) in reply to LordHunter317

    Anonymous:
    Anonymous:
    You are contradicting yourself.  I think we all understand (and agree with) your overall point, but using the word "crash" is wrong.
    No, I'm not.  Show me  a logical proof of how "abnormal program termination" also know as a "crash" is conflicting with saving a user's work before terminiation.

    Word does it, Visual Studio 2005 does it, so don't bother with that proof.  It would instantly be logically invalid due to proof by counterexample.


    So, in your terminology,  you say a program "crashes" when it saves its work, alerts the user with a nice message, cleans up resources, and then exits. 

    Do yourself a favor -- on your next job interview, don't tell a potential employer that your coding skills are great because your apps "always crash", expecting them to use your same definition.  When you write your apps, does your File menu have "Open","Save" and "Crash" as the options?

    Just out of curiousity, what do you call it when a program ends abruptly, loses data, and doesn't clean up resources?

  • (cs) in reply to dhromed
    dhromed:
    SeekerDarksteel:
    Anonymous:
    Anonymous:
    Anonymous:
    StarfishC:
    Anonymous:
    Anonymous:

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

    yeah but there's a catch{} to everything

    I hope you guys have finally{} got those awful puns out of your system!


    Sorry, they won't be going for a while{}


    for() goodness sake!

    I can see that this will REPEAT UNTIL someone gets hurt.


    do{} your worst!

    if{} you guys cut this out I'll be happy, else{} I'm gonna have to get angry!



    this.isGetting() ridiculous. I will GOTO try{} && catch(){} the NEXT bus out of here, because this.isDriving() me insane.

    Enough already, we need really need to switch(this.topic) { in case: we break; something and need to find where deFault; lies}

     

  • LordHunter317 (unregistered) in reply to Jeff S
    Jeff S:
    So, in your terminology,  you say a program "crashes" when it saves its work, alerts the user with a nice message, cleans up resources, and then exits.
    Yes.  A crash is any abnormal termination of a program that the user cannot stop.  Whether the application tells the user it's doing so, attempts to perserve the user's work, or does nothing at all is irrelevant.  From the user's perspective, the program still terminiated without their permission and without giving them a chance to prevent it from occuring.

    And hey, under many modern lanaguages and frameworks, I get some of that for free.   Windwos displays a "nice" (for certain definitions of nice) dialog for me.  Resource cleanup is gauranteed in any language with exceptions if you wrote your code correctly, and have to do for non-fatal exceptions.

    The only requirement for a crash is that it happens abnormally, and the user cannot stop the termination.

    When you write your apps, does your File menu have "Open","Save" and "Crash" as the options?
    No, but this is a non-sequitur.  Quitting isn't abnormal terminiation.

    Just out of curiousity, what do you call it when a program ends abruptly, loses data, and doesn't clean up resources?
    A crash.  Not cleaning up resources and losing data is irrelevant to the definition of what a crash or what abnormal program terminiation is.  You may not like it, but no dictionary includes not cleaning up resources and losing data as requirements for a crash.

    Moreover, properly written .NET or Java code will always clean up resources in the face of an exception, regardless of whether it's fatal or not.  So if we go by your definition, then no Java or .NET application I've ever written "crashes", because they all free resources through finally clauses. 

    Yet, the thick-client application had bugs that would result in program terminiation.  Any sane user would call this a crash.  So obviously, including resource cleanup makes the definition nonsensical.

    A similar argument can be extending to saving the user's data, or attempting to do so.  Word will attempt in certain crash situations to force an autorecover (it also writes autorecover periodically for the cases when it cannot).  Did it still not crash?  I still have to restart the application, tell it to recover my document, and then save my changes.  Any user would call that a crash, and I don't see any valid reasoning presented thus far as to why it shouldn't be considered one.
  • John Hensley (unregistered) in reply to ferrengi
    ferrengi:
    Anonymous:
    I SO do not believe this is for real.
    This is made up.


    Agreed.
    How can it be that the guy learned System.Reflection and delegates but is totally clueless on how try-catch is supposed to be used?

    Apparently he knows just enough to think he knows everything.

  • Dange (unregistered) in reply to Joost_
    Joost_:

    cough <FONT size=1>(checked exceptions)</FONT> cough

     

    Ah yes the joys of Java.  I particularly love it when your teacher has a try { doSomething() } catch(Exception e) { } and he says you should do that when you get "some error" about exceptions when compiling.

  • Jon (unregistered) in reply to OneFactor
    OneFactor:
    Enough already, we need really need to switch(this.topic) { in case: we break; something and need to find where deFault; lies}
    delete this;
  • Rappo (unregistered) in reply to jmeyer43
    jmeyer43:

    No, in VB next means next... in this case, handle errors by going to the next statement and continuing!

    Of course I whole-heartedly agree abuot what the error handler SHOULD do, but VB's "on error resume next" doesn't do any of that

    Okay, I am a VB programmer (though I mostly work in VBA). On error resume next is actually quite usefull, it should be used to make a psudo try statement. Something  like:

    On Error Resume Next

    DoSomething

    If err.Number = SomeNumber then

    on error goto broken

    ....

    Else

    on error goto realy_broken

    .....

    End If

    Like I said it has justifiable uses... of course I do believe VB.net has try,catch,finaly nowdays, so it realy shouldn't be around much longer (except maybe in VBA).

  • (cs) in reply to Dange
    Anonymous:
    Joost_:

    cough <FONT size=1>(checked exceptions)</FONT> cough

     

    Ah yes the joys of Java.  I particularly love it when your teacher has a try { doSomething() } catch(Exception e) { } and he says you should do that when you get "some error" about exceptions when compiling.

    My favorite is the sourcecode to Tomcat 3.? which had: catch (TomcatException e) { // what to do?}

    I know it really sux to have a stack trace visible to the end user. But it's even worse to have a stacktrace invisible to the poor sap who has to fix the problem. The number of times I've had to walk into a system I did not write and try and find that missing stacktrace and make it somehow available in the log files, console, or the ui because of those stinking checked exceptions being caught and swallowed.

    It all sounded so nice on paper. The compiler would force us lazy developers to write better code and it resulted in worse code. And then all the stupid defenses about how people were not supposed to swallow checked exceptions. In truth, the lazy developer would never have committed the atrocity in the first place were it not for checked exceptions. So in essence the compiler was made to complain about a bad problem and went silent when someone made it worse. Brillant.

  • (cs) in reply to John Hensley

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


    Agreed.
    How can it be that the guy learned System.Reflection and delegates but is totally clueless on how try-catch is supposed to be used?

    Luke: I don't believe it.
    Yoda: That is why you failed.

  • omnilord (unregistered) in reply to headhigh
    Manni:
    One alternative is "On Error Goto", which is just frickin scary and amateurish to use. I want to handle my errors, not jump to a certain line in my code whenever something goes wrong.

    I'm surprised no one brought up the "other" method of error handling in VB: subclassing.  Yes, it is VERY ugly, but it allows you to handle the raw errors, and test for recoverability without getting messy like it does with On Error.  Wish I still had it so I could show it to you.

  • (cs) in reply to triso
    triso:
    <font size="5">H</font>ence the expression, "A little knowledge is a dangerous thing." --Alexander Pope

    It should be "A little learning is a dangerous thing", it's a very common misquotation.
    Yes I am being picky but then what is this website about ?:D

    Personally I think the coder in question has a fine career ahead of him in marketing.
  • Urkki (unregistered) in reply to LordHunter317
    Anonymous:

    The only requirement for a crash is that it happens abnormally, and the user cannot stop the termination.


    But the real question here is, what is considered "abnormal"?

    For GUI applications it's generally easy.  If the program quits without a user or the operating system telling it to quit, you could say it crashes.  Also if fails to exit gracefully (and possibly loses data when it is killed) when operating system tells it to quit gracefully then that'd count as a crash.

    But with software like command line applications or CGI-style Web applications, it's less clear.  A message "The image you wanted to view does not exist" (on a web page or on terminal) and then exit(1) is certainly not crashing, even though exit happens because of an error and return error code.

  • (cs)

    A typical result of books like "Learn what-ever-programming-language in 7 days" or ".Net step-by-step for VB programmer"  .. lol 

  • LordHunter317 (unregistered) in reply to Urkki
    Anonymous:
    But the real question here is, what is considered "abnormal"?
    That's application defined, with the only universal definition for exception-based langauges is that an exception that goes past the application's calling stack is a crash.

    But with software like command line applications or CGI-style Web applications, it's less clear.  A message "The image you wanted to view does not exist" (on a web page or on terminal) and then exit(1) is certainly not crashing, even though exit happens because of an error and return error code.
    ASP.NET applications and Java Servlets are free to crash by throwing an exception and letting it propogate up, the underlying server code catches it.  This is a "crash" of that particular servlet, for all practical purposes.
  • pmagill (unregistered) in reply to LordHunter317
    Anonymous:
    Jeff S:
    So, in your terminology,  you say a program "crashes" when it saves its work, alerts the user with a nice message, cleans up resources, and then exits.
    Yes.  A crash is any abnormal termination of a program that the user cannot stop.  Whether the application tells the user it's doing so, attempts to perserve the user's work, or does nothing at all is irrelevant.  From the user's perspective, the program still terminiated without their permission and without giving them a chance to prevent it from occuring.


    I have to take difference with this as I do not see it as a crash if you were able to save the users work, regardless if the user can intervene.  The reason behind this is you actually coded it so the user could not intervene, it was your decision to choose that process flow.  You could have easily captured an event (let's say a database read fails) and decided that since you can't connect you will simply exit out.  Alternatively you could simply tell the user about the failure and present them back to the menu screen or whatever.  The user could be free to try again or not, trying again does not garuntee success.

    In this case, if you took the first option and simply unloaded the application you would call it a crash, when in the second you would not.  So you are saying you code your applications so that they are intentionally not user friendly?  If you as the developer are able to capture the exception and make a decision following the exception it is not a crash in my eyes, but rather the program shoosing to terminate gracefully without the users permission.  Yes from the users eyes tis would be a "crash" but you as the developer can simply make a different decision in the exact same environment adn the user is left feeling that the application attempted to do something, failed and responded in a friendly manner.

    I think a later poster said it best when he stated that a crash is more like an error then raises outside of the application scope.
  • (cs) in reply to StarfishC
    StarfishC:
    Anonymous:
    Anonymous:

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

     

    yeah but there's a catch{} to everything

     

     

    I hope you guys have finally{} got those awful puns out of your system!


    Sorry, they won't be going for a while{}

     

    I'm all for() stopping this now.

    this post is not [pi]-approved

  • john bigbooty (unregistered) in reply to dasmb
    Anonymous:
    Just ask any Notes developer (provided he isn't doped up on morphine...i understand that's the only way some of them make it through the day).

    ROTFLMAO... Whenever I had to work on a Notes Server, I would suddenly contract a case of Tourette's syndrome.

    Nice to know that the Notes developers were numb from the pain that crap would cause.

  • LordHunter317 (unregistered) in reply to pmagill
    Anonymous:
    I have to take difference with this as I do not see it as a crash if you were able to save the users work, regardless if the user can intervene.
    That's not true though.  I could have encountered a logic error where it's not safe to continue (i.e., passing a null where one shouldn't have been passed) but can still make the asertation it's safe to down.

    In some situations, like kernels, you can run into a similar state: if a driver goes bad, you may have to shut down, since it cannot recover without a reset, but you can still write a crash dump out to disk or serial port before shutting down.

    You could have easily captured an event (let's say a database read fails) and decided that since you can't connect you will simply exit out.  Alternatively you could simply tell the user about the failure and present them back to the menu screen or whatever.  The user could be free to try again or not, trying again does not garuntee success.
    And in many situations, that's the appropriate action.  But in some situations, you can't sanely back out to where the user can gain control.  For better or worse, you must exit.

      So you are saying you code your applications so that they are intentionally not user friendly?
    No, I code them so they are correct.  This means not swallowing exceptions that can't be safely swallowed.

    I think a later poster said it best when he stated that a crash is more like an error then raises outside of the application scope.
    And in most managed languages, half of the exceptions refer to events outside the program scope.  The other half refer to logical errors that were made on behalf of the programmer.
  • pmagill (unregistered) in reply to LordHunter317
    Anonymous:
    Anonymous:
    I have to take difference with this as I do not see it as a crash if you were able to save the users work, regardless if the user can intervene.
    That's not true though.  I could have encountered a logic error where it's not safe to continue (i.e., passing a null where one shouldn't have been passed) but can still make the asertation it's safe to down.

    In some situations, like kernels, you can run into a similar state: if a driver goes bad, you may have to shut down, since it cannot recover without a reset, but you can still write a crash dump out to disk or serial port before shutting down.

    It is true, I DO see it this way.  Saying that it is untrue that I see it that way is never write.  Although I think you were saying something else is untrue, but it is unclear here.  On the other side, you example of failing on nulls doesn't seem to be a good argument as you can check your passed variables for null and not process and instead inform the user, or replace it with a seemingly valid piece of data (perhaps 0 for numerics or an empty string for strings).  I agree this may not always work out but saying that simply passing a null is a reason for a "crash" isn't good

    You could have easily captured an event (let's say a database read fails) and decided that since you can't connect you will simply exit out.  Alternatively you could simply tell the user about the failure and present them back to the menu screen or whatever.  The user could be free to try again or not, trying again does not garuntee success.
    And in many situations, that's the appropriate action.  But in some situations, you can't sanely back out to where the user can gain control.  For better or worse, you must exit.

    I agree here also, and in that case I would consider this a fatal exception perhaps a crash.  Note my difference in terms here.  A fata exception is something that you can not continue on but will be able to do some processing afterwards such as saving the users work.  A crash is just that, total failure, no more processing, complete shutdown.

      So you are saying you code your applications so that they are intentionally not user friendly?
    No, I code them so they are correct.  This means not swallowing exceptions that can't be safely swallowed.

    Correct in this case is an opinion I think.  There are many way to do something, many wrong ways and many right ways.  Who's is better?  It depends on this situation.

    I think a later poster said it best when he stated that a crash is more like an error then raises outside of the application scope.
    And in most managed languages, half of the exceptions refer to events outside the program scope.  The other half refer to logical errors that were made on behalf of the programmer.

    Yes half the exceptions happen outside the program scope but under it.  Notice I stated raised outside the program scope which means above it.  A file not found error is outside the scope of the application as it is raised from the file system, but it is also under the application and can be captured by the application.  Anything not handled by the application and simply thrown up the stack until the application goes out of scope is what I am referring to here.

    In the end, I think we are simply arguing semantics.  You are using the term "crash" in a broader sence then myself and a few others.  Others here may completly agree with you.  Are either of us more right then the other?  I don't think we can really answer that.  It comes down to local standards and practices sometimes.  Persoanlyl I like to use "Fatal Exception" for something I can continue processing on but still need to exit the application without consent from the user and "Crash" I use for the times that something so catastrophic occurs that there was nothing my application can do to prevent it.  Don't go saying that My version of "crash" will never happen, just look to hard drive failures or corrupted/bad memory for these things.
  • pmagill (unregistered) in reply to pmagill

    Let me add one more thing to this discussion.  I stated and tried to explain my terms of Fatal Exception and Crash above.  This is from a programmers point of view.  To the user, these two different scenarios are simply the same thing, a crash.  So the term "crash" can mean slightly different things depending on your point of view or point of reference.


    CATCHA = dinky, like this post compared to others

  • HEHEHE (unregistered) in reply to pmagill

    HAHAHAHAAH... I locked you out! :P

  • rmao (unregistered) in reply to Runtime Error
    Anonymous:
    Whie the Java version is nice, there is still to much code hardcoded in the, uh, code.  What he needs to do is to move all those function names and arguments to an XML file and write a class to parse that and execute it through reflection, all the while discarding all those pesky exceptions.


    I hear the next version of Spring has that.
  • (cs) in reply to Rappo
    Anonymous:
    jmeyer43:

    No, in VB next means next... in this case, handle errors by going to the next statement and continuing!

    Of course I whole-heartedly agree abuot what the error handler SHOULD do, but VB's "on error resume next" doesn't do any of that

    Okay, I am a VB programmer (though I mostly work in VBA). On error resume next is actually quite usefull, it should be used to make a psudo try statement. Something  like:

    On Error Resume Next

    DoSomething

    If err.Number = SomeNumber then

    on error goto broken

    ....

    Else

    on error goto realy_broken

    .....

    End If

    Like I said it has justifiable uses... of course I do believe VB.net has try,catch,finaly nowdays, so it realy shouldn't be around much longer (except maybe in VBA).

    On Error of any sort is not particularly useful, unfortunately it's the only option in VB 6 and earlier.  People use it because they have to.  Here is where your sort of rationale will take you...  Suppose you are lost in the jungle, seperated from your exploration party.  After a day or so you get really hungry and the only things you can catch and eat are bugs.  The bugs sustain you for two weeks and after that time, you are rescued and taken back to wherever it is that you live.  Therefore, eating bugs is a good thing.

  • (cs) in reply to jsmith
    jsmith:

    On Error of any sort is not particularly useful, unfortunately it's the only option in VB 6 and earlier.  People use it because they have to.  Here is where your sort of rationale will take you...  Suppose you are lost in the jungle, seperated from your exploration party.  After a day or so you get really hungry and the only things you can catch and eat are bugs.  The bugs sustain you for two weeks and after that time, you are rescued and taken back to wherever it is that you live.  Therefore, eating bugs is a good thing.



    Depends on the implementation, really. When IBM added a scripting language to the Notes/Domino platform it copied VB syntax and conventions, but one of the changes they made was to the On Error statement. In LotusScript, the statement can be general (as in VB6), or specific:

    On Error (error number) Goto (handler label)

    ... and there can be multiple concurrently-effective On Error statements in any given module (as long as you watch the order, since a general statement after a number-specific statement will override the former). In essence, that makes error handlers equivalent to catch(specificExceptionType e) {...}. And it is also possible to "rethrow" using the Error statement. And no, it is not any more evil than try-catch in terms of maintainability or readability unless one lets ones modules get out of control.
  • (cs) in reply to HEHEHE
    Anonymous:

    HAHAHAHAAH... I locked you out! :P

    Yeah, good job, idiot.
  • David (aka TheCPUWizard) (unregistered) in reply to c--

    I am not that Dave...I am not that Dave... I am not that Dave!!!!!!!

     

  • Anon (unregistered) in reply to ferrengi
    ferrengi:
    Anonymous:
    I SO do not believe this is for real.This is made up.
    Agreed.How can it be that the guy learned System.Reflection and delegates but is totally clueless on how try-catch is supposed to be used?

    This is because as soon as you find yourself trapped in a strongly typed language, you start looking for ways out of the trap.

    So half the C++ programmers out there know more about casts than they know about OO.

Leave a comment on “The Perils of Error-free Code”

Log In or post as a guest

Replying to comment #59388:

« Return to Article