| |||||||||||||
Exceptions vs Error CodesExceptions vs Error CodesPosted Mar 30, 2012 16:14 UTC (Fri) by nybble41 (subscriber, #55106)In reply to: Exceptions vs Error Codes by dgm Parent article: Go version 1 released
> If by "transparently" you mean that the code can automatically unwind the stack frames of several unsuspecting functions, you're right. _All_ exceptions systems I know of do this.
IIRC, in Java you have to declare which exceptions a method can raise, including any which might be raised by lower-level functions, unless they are handled internally. So there are no "unsuspecting functions"; the only stack frames which an exception will unwind are those which declared that exception in the prototype. C++ has a similar feature, but it's optional, so it doesn't provide the same guarantees.
Of course, any language which supports non-local returns--including captured continuations and C's setjmp()/longjmp() routines--potentially has the same issue. Exceptions fall somewhere in between, since unlike setjmp() they allow for cleanup in the intermediate stack frames, but unlike continuations they are not (typically) flexible enough to implement arbitrary flow control.
(Log in to post comments)
Exceptions vs Error Codes Posted Mar 30, 2012 16:22 UTC (Fri) by khim (subscriber, #9252) [Link] So there are no "unsuspecting functions"; the only stack frames which an exception will unwind are those which declared that exception in the prototype. That's why huge amount of Java code includes empty catch statements. And still RuntimeExceptions blow up programs regularly. I'm not sure if it's even possible to sanely use exceptions, but C#/Java exception handling is disaster. In my experience exceptions are useless in most cases: sometimes you really want to compartmentalize your program, but fork(2) works fine in such cases. If your task is not large enough to use fork(2) then it's probably not large enough to warrant complex exception-based schemes.
Exceptions vs Error Codes Posted Mar 30, 2012 19:24 UTC (Fri) by dgm (subscriber, #49227) [Link]
On the other hand, exceptions tend to work nice when you have to repeatedly call library functions that almost always work as intended (that is, errors are really exceptional). In that case you can save a lot of error checking and write simpler code.
Working with exceptions is tricky, but if you know (and follow) the rules it's not more difficult than treads or pointers (:-P)
I will not pretend to know all the rules, but those have served me well:
1. Never, EVER add exceptions to code written without them in mind (this applies basically to C/C++). If you want to use exceptions, do so from day one, or rewrite unaware code.
Ah, just one more thing: don't feed them after midnight. Just don't do it.
Exceptions vs Error Codes Posted Mar 30, 2012 22:01 UTC (Fri) by khim (subscriber, #9252) [Link] On the other hand, exceptions tend to work nice when you have to repeatedly call library functions that almost always work as intended (that is, errors are really exceptional). In that case you can save a lot of error checking and write simpler code. Yup. And as added bonus it'll guarantee your future employment when you'll find and fix dozens of security bugs and DOS cases. 4. Program defensively, specially when holding resources (open files, locks, connections, memory). Expect unexpected exceptions everywhere. Your code will probably have a longer and more interesting live than you expect. This is what makes exceptions pointless. It's hard enough to find programmers which can correctly programs the common case. Someone who can correctly program all the exceptional codepaths will be usually too expensive. And will still miss some cases. This is where fork(2) solution saves your beacon: sure, you still need to somehow handle cases where some shared resources (such as pipe or shared memory) misbehaves because other process died but most of the heavy lifting will be done by OS without your direct involvement: sockets will be freed, files will be closed and removed (you do remove temporary files right after open(2) call, because you need to handle poweroff case, right?), etc. Go is trying to create something like this in a single process - but I'm not 100% sure how well it'll work.
Exceptions vs Error Codes Posted Mar 30, 2012 23:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>This is what makes exceptions pointless. It's hard enough to find programmers which can correctly programs the common case. Someone who can correctly program all the exceptional codepaths will be usually too expensive. And will still miss some cases.
Nope. It's easy in C++ - just wrap everything in RAII-based holders. If you need a cleanup action then wrap it in ON_SCOPE_EXIT macro or make it a lambda function (C++11 is great!). Pretty easy once you get used to it.
On the other hand, meticulously handling return codes just doesn't happen if you don't force it through code reviews.
Exceptions vs Error Codes Posted Apr 2, 2012 8:02 UTC (Mon) by jezuch (subscriber, #52988) [Link]
> That's why huge amount of Java code includes empty catch statements. And still RuntimeExceptions blow up programs regularly. I'm not sure if it's even possible to sanely use exceptions, but C#/Java exception handling is disaster.
Nope. The reason for this is huge amounts of lazy and clueless programmers. And Java's exceptions are far from being a disaster. I actually love them, despite some wrinkles. There was a time when I submitted to this "exceptions are evil, declare everything as throwing Throwable" movement and I regretted this ever since. I'm also reminded of this every time I have to code something in C and error handling becomes a chore and pain even worse than manual memory management ;)
|
|||||||||||||