As a side note, at least in Objective C, blocks are a great way to return multiple values (including errors) and deal with them immedately.
Exceptions (2003)
31–40 of 93 posts
Re: Exceptions (2003)
#32> [as an alternative to exceptions] "It is true that what should be a simple 3 line program often blossoms to 48 lines when you put in good error checking, but that's life Was he being serious? I'd rather not wade through all that error checking cruft to see normal flow. Exceptions (or goto) don't create buggy hard to read programs, people do.
Except that error handling is part of normal flow.
Wishing it wasn't, or just laziness, leads to bugs. It's not cruft, it's integral. That's the whole point.
Re: Exceptions (2003)
#33I am not a huge fan of exceptions per se, but it’s important to understand that they are a heuristic for minimizing ‘worry’ about things that are unlikely. I am not saying it’s a good thing, I am saying it’s the way people naturally work. Let’s say there is a function that’s 20 lines long, and if you did a thorough analysis of possible error conditions, regardless of likelihood, you might come up with 50 or more. We…
50 error conditions in a 20-line function doesn't really sound even remotely realistic. Probably only 5 of the 20 lines are actually calling functions that might return errors, and in most cases, we don't care what type of error is being returned.
So if we're talking about 5 error-checks in 20 lines, then yes, we absolutely should write code to address them from the start.
I mean, I can understand not dealing with errors from memory allocation failing, or even possibly failure to write bytes to disk, depending on the situation (e.g., if those fail, you've got bigger problems to worry about than your error handling -- and it's not like exceptions are probably helping you to recover anyways).
But for stuff like network communication, writing to databases, etc., you had definitely better be addressing all error possibilities from the start, because these things fail all the time.
Re: Exceptions (2003)
#34Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…
Going one step further on the file example, I had a college professor who wrote a function read from a file that had no end except an exception thrown by the read because the file was at its end[1]. He said the end-of-file was an exceptional circumstance for a function that expected to read and process a line.
I doubt anyone would say end-of-file is unexpected, but I am not sure I would say it was exceptional.
1) something like this (it has been 20yrs)
init data structure S
open file A
loop
read line from A
process line and add to S
next
catch EOF
close A
return S
catch file-not-found
return empty S
Re: Exceptions (2003)
#35If you're catching exceptions all over the place, or worse using them for flow control as part of normal operations, you're doing it wrong. Exceptions should indicate a major error that you can't easily recover from and as such should be caught and logged at the top of the stack, i.e. the main thread run method or request handler. When used that way, they give you very useful information as to what went wrong and whe…
I think most people have been brain damaged by checked exceptions in Java. It comes with this expectation that need to have to catch block in almost every single function. But if you do that, you've just recreated error codes and multiple returns!
Exceptions are meant be thrown frequently and caught very infrequently. Catch in the few places where recovery is possible and where you can log the error. That's it.
Re: Exceptions (2003)
#36Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…
It's possible for a library to return an error to indicate that a file is not found when you try and open a non-existent file. Then it's possible for a function that calls the open file function to decide whether that error should be translated into an exception i.e. should that file being missing break out of the current execution? There's no race condition there.
I don't think anyone reasonably expects a library to know the context of the file being opened and its importance in the logic of the rest of the program.
Re: Exceptions (2003)
#37I think Common Lisp has a good approach with its restarts system. I try to write something to a file but there is not a enough disk space? How about telling the user, then invoking a restart when the user says, "There is more space available!" and continuing execution as if nothing went wrong? The problem with exceptions is that there is no way to recover from them in most languages, because the exception handler is found by unwinding the stack.
What I do not like about the "check return values" approach is:
1. It means that client code must understand how to handle error conditions. No disk space? Well whoever called the top-level function that invoked write needs to figure out what to do if there is any chance of recovery. It is a maintenance headache that can quickly accumulate bugs.
2. In both Java and C++ there are functions that cannot return values: constructors, and in C++ destructors. No, it is not acceptable for a program to crash just because a constructor call failed. No, it is not any better to have every class have a special variable that indicates that the constructor failed. No, having empty constructors is not the answer, and it is certainly not going to help with destructor calls (the C++ standard library actually requires some destructors to silently fail because of the issues with error reporting).
Re: Exceptions (2003)
#38Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…
> you are trying to open a file for reading. The file does not exist. Is this exceptional?
It's actually handy to have an API that includes both situations. For example, parse and tryParse in C#. Parse will trigger an exception if it fails but tryParse will not. When used in your code, this actually documents what the programmer is expected. If an open and tryOpen operations existed, you would know whether or not the programmer expects the file to exist or not.
Re: Exceptions (2003)
#39The advantage of exceptions is the ability to pass back the error and make mandatory dealing it (even if ignoring).
Exist a way to have both styles, cleanly?
I have thinking in how could look a language where objects, like in UNIX pipes, have stdout & stderr, and if stderr is consumed (returning codes) the exception is handled, but if stderr is not consumed, then raise it?
Re: Exceptions (2003)
#40[deleted]