Re: Try/Catch
- Posted by jimcbrown (admin) Jan 08, 2015
- 5785 views
OK, to set the tone, for me three things are certain: death, taxes and when I see (in C++)
int main(int argc, char **argv) {
try {
}
catch (...) {
}
}
Then I know that I am facing some seriously badly written and almost completely untested garbage code.
Obviously for some small part, fair enough, but the whole app? - alarm bells.
I've done this before, though not often. It provides a way to perform a last-ditch 'save all the ciritical data now!' method.
I have stated that I prefer long-winded and tedious error code handling over exceptions.
If I had the chance, I'd do both. The former lets me do proper validation and is often faster - but it can't deal with the unexpected, hence the need to use the latter.
These would always be non-recoverable exceptions .. Control does not return to the application.
a chain of such routines
Not making much sense to me so far.
There's precedent for this in other languages. It's tough to catch and stop a ThreadAbortException in Java. And while OOM exceptions can be caught, it's pretty hard to continue as normal if one of those get thrown...
The thing here is that the example is not an exception, in my opinion.
granted.
That example should obviously be a recoverable error. If it were a function (x = slice(s, i) then it's possible to signal an error by the return value or something, the same method that open() uses when it can't open a file. But Euphoria provides no way to recover from the error in the original example. This is the root of the problem.
I regard exceptions as those things that originate from outside the control of an application and that cannot be effectively anticipated by it. That's why the application should terminate, possibly after doing some damage control/mitigation first.
That might be a better definition of exception, but I don't get that the only response to things beyond your control is to die.
I've seen code in Java where Throwables are thrown and caught for purposes unrelated to error handling. For example, there's a method that returns an integer, but someone wnated to modify it to return a string in some cases. So when a string has to be returned, a new Throwable is thrown with the return value embedded in it, and the caller catches the Throwable and extracts the string from it. (While this is one way to accomplish the desired result, there are better ways to do it.)
I have no problems with Derek's definition of exceptions, but that limits its usage to things like OOM or other issues that are fundamentally hard to deal with in a sane way. Throwables and the try/catch framework can be used for more trivial issues (like open() not being able to open a file) that can be effectively anticipated by the application. In fact, as in my example above, they can be used for purposes entirely unrelated to error handling altogether.
While in theory I can anticipate range errors, this is tricky in practice.
I'd rather be using a language that allows me to gracefully recover from exceptions, than one that crashes.
Certainly, an editor that gracefully handled an unanticipatible exception by warning the user and giving the user a chance to save all their data would look a lot more professional that one that simply threw up a GP fault and vanishes along with all that user's hard (and unsaved) work.
A bug in the editor should result in a crash, and the developer should correct the bug. If possible, the reason for the bug should be communicated to the user, but regardless if an incorrect result can occur then the user is better served by a crash then by the output of incorrect data.
This is part of the Unix philosopy - broken programs deserve to break. (Example at http://lwn.net/Articles/414467/ )
But when data is lost, it looks really unprofessional. In one case, it even lead to enough unhappiness that the threat of a lawsuit was thrown around: http://photo.net/wedding-photography-forum/00brg3
On the other hand, the output of incorrect data in software has lead not only to big lawsuits but even to people dying: http://www.law.berkeley.edu/journals/btlj/articles/vol5/Levy/html/text.html
Of course, the class of errors represented by an illegal filename would be classified as a recoverable error, not necessarily an irrecoverable one. It's a situation which depends on user input and should be checked by code so...
I'm not sure that your example is valid.
I don't understand. Your program takes input, uses a library which returns incorrect output, and so you should provide some random or guessed output regardless? If the library is bad, then the application should crash and you should provide feedback to the library developer. If he or she is unavailable then you should no longer use that library, or else correct it on your own.
These issues should certainly be identified by testing prior to deployment.
If your program RECEIVES incorrect input, then it should detect it and report it back to the user.
Well, this happened to dcuny while he was actively developing and testing his editor, prior to the deployment of even an alpha version. If try/catch makes it easier for developers to eat their own dog food, I don't see why that'd be a bad thing.
