- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
!this.isFunny()
Admin
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.
Admin
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.
Admin
Im going to catch{} the guy who started all these bad puns
Admin
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
Admin
What do you think try/catch/throw is?
Admin
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.
Admin
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?
Admin
Enough already, we need really need to switch(this.topic) { in case: we break; something and need to find where deFault; lies}
Admin
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.
No, but this is a non-sequitur. Quitting isn't abnormal terminiation.
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.
Admin
Apparently he knows just enough to think he knows everything.
Admin
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.
Admin
Admin
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).
Admin
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.
Admin
Luke: I don't believe it.
Yoda: That is why you failed.
Admin
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.
Admin
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.
Admin
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.
Admin
A typical result of books like "Learn what-ever-programming-language in 7 days" or ".Net step-by-step for VB programmer" .. lol
Admin
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.
Admin
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.
Admin
I'm all for() stopping this now.
this post is not [pi]-approved
Admin
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.
Admin
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.
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.
No, I code them so they are correct. This means not swallowing exceptions that can't be safely swallowed.
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.
Admin
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
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.
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.
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.
Admin
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
Admin
HAHAHAHAAH... I locked you out! :P
Admin
I hear the next version of Spring has that.
Admin
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.
Admin
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.
Admin
Admin
I am not that Dave...I am not that Dave... I am not that Dave!!!!!!!
Admin
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.