51–60 of 93 posts
> [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.
Earlier quoted context omitted.
Nonsense. Is the network up? Is the connection to SQL up? Did someone just turn off the SQL machine half way through the query? Can we find the server? Are there any rows? Did the SQL compile? Do I have rights on this table? Have you just terminated me as a result of a deadlock? Did you return a Null when I was expecting a value? Did you return a float when I was expecting an int? Did my value just overflow? Did you…
Functions should be scoped appropriately so that they only deal with one thing at a time. A function that checks for network connectivity isn't going to be checking for missing rows. Those are different problems, and should be handled by different functions. Using your example, we have a function that queries a database. It will be given a valid database connection, and return the result of the query. There is no "va…
> [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.
1. Avoid action-at-a-distance and side-effects that are hard to reason about.
2. Use immutable objects and values rather than references and pointers.
3. Avoid intricate control flow with many branches.
4. Greater isolation of processes/threads (actor model).
5. Use systems and platforms with simple and strong guarantees (e.g. ACID) that are easy to reason about. Special cases and nuances to the underlying platform should be avoided.
6. Use tools with good support for static analysis (e.g. a good type system with a compiler that can understand it).
Exceptions seem to violate #1, #3, and #6.
These rules only apply to software engineering; that is, the reliability, robustness, long-term maintainability, and total project development cost (including maintenance and support).
Of course, there are other considerations, such as: performance, the time to achieve the minimum viable product, how much developers like the tools, how "hackable" it is, or utility for research purposes. These other concerns may be a good reason to violate the above rules.
Exactly fits the philosophy of Google Go - http://blog.golang.org/error-handling-and-go I think his point of there being easy syntax for multiple returns is critically important to make this sort of error handling non annoying - which Go does remarkably well. I think this factor has a lot to contribute to the fact that you get the warm fuzzy feeling after your code compiles. You feel confident that you have already h…
What about the errors you don't care about at the time, but realize later than you should care about? Do you go back and add them? This process seems error prone to me.
From the Go FAQ "[Excpetions] also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional."
So the problem is not with exceptions, but how some programmers use them.
Earlier quoted context omitted.
The name of the language is Go, not "Google Golang" That said, this was, for me, the single weirdest thing to get used to when starting to program in Go, coming from a mostly Python/Java exception-style background. (I imagine it's easier if you're a C programmer). However, once I got into the swing of it, I realized I really, really like Go's error handling, and I can't imagine going back to Python's exceptions volun…
I have to say, I much prefer people referring to it as Golang, otherwise it is impossible to search for.
Earlier quoted context omitted.
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) som…
In Java, everyone would tell you this is wrong. In Python, this is the normal way to end an iteration (specifically, throwing StopIteration). It's not a huge leap to see a stream as an iteration over bytes. So, what's considered exceptional seems somewhat culturally dependent.
Everyone 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…
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
edit: Oh. http://c2.com/cgi/wiki?BondageAndDisciplineLanguage ? Makes sense.
Everyone 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…
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
Related discussions:
- http://stackoverflow.com/questions/8805238/run-time-penalty-...
- http://stackoverflow.com/questions/299068/how-slow-are-java-...
I 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…
I really wish more people knew about this option. Maybe it would even get into mainstream languages.