Error Codes or Exceptions? Why is Reliable Software So Hard?
damienkatz.net
damienkatz.net
The one thing that makes working with exceptions is that when one is encountered the stack is unwound up to the first matching handler (and possibly just passed off to the next one, etc). You can lose a lot of state this way and it makes restarting computations difficult (or even deciding what to do in some cases).
Using exceptions just requires careful planning and I think conditions and restarts are a much more elegant way of solving the problem.
For example, in the Tornado web stack, it’s certainly possible to gracefully handle an exception you threw in the middle of responding to a method, but you have to basically augment the framework to do so. It’s practically unfinished in that sense. Would that have been the case if it were designed with failure modes occupying its creators’ minds even half as much as successful ones?
†The most fun example/intro to this I’ve seen: http://www.fanfiction.net/s/5782108/8/Harry_Potter_and_the_M...
Yes, this realization finally hit me a few years ago and started to make me reign in my use of exceptions. I realized that exceptions are all about giving priority to the optimistic case in the code - making it as clear and simple and with as little branching as possible. However after seeing projects through a full lifecycle (from initial conception through to maintenance in production) I now realize that the really important code - the code that we spend most of our time trying to figure out in maintenance over the lifetime of the application and whose state is most hard to understand and deal with - is in fact the error handling code and that exceptions focus on hiding that code and making it "disappear" and seem implicit. What seems like a win initially can be a huge loss when you're trying to write a robust system where every possible behavior is explicit and well understood.
Many common problems, especially in network servers, can be solved quite elegantly with an "exception driven design". In those scenarios the exceptions serve as a vehicle to bubble state through multiple layers. Pretty much like an event-framework, except many people don't realize they have that baked right into their language.
A simple example would be a network-server that detects a protocol phase change at the lowest protocol level. By raising a "PhaseChange"-Exception you can quite nicely propagate such an event to the higher layers that need to know about it, without resorting to duplicated/shared state or awkward call-chains that introduce nasty dependencies and then need their own exception handling, and without running into potential synchronization issues.
I lost my interest at "PHP to the Rescue". I understand the point he tried to make, but he's wrong.
PHP (or CGI/FastCGI for that matter) only works because the computation done on each request is very light and it maps well with the HTTP protocol which is at its core a stateless protocol. But it only works because the real work of indexing, searching and retrieving of documents gets pushed to the database server, a piece of software that does serious gymnastics to serve the results you want. The database server does give you ACID and it does this precisely because it can UNDO and once the database server crashes, all hell breaks loose.
A better example in this context would be Chrome, which sandboxes each tab inside its own process, such that the crashing of a tab doesn't affect the whole browser. But tabs themselves have to be long-running and stable, and those tabs are still crashing and valuable work may still be lost, not to mention the whole browser still freezes because of plugins that haven't been fully sandboxed.
Also, it doesn't warm my heart when I lose an hour's work, even if the other tabs haven't crashed.
Don't Undo Your Actions, Just Forget Them
... Use a Functional Language
Once a file is changed, it stays changed (sorry, you'll have to replace the OS to avoid it and what can I say, good luck with that). Once an email is sent, it stays sent. Once a phone call is made, you can't really pretend that it isn't. Once a bank transaction is made, you have to undo it if anything went wrong, otherwise you're facing serious penalties.
Not dealing with mutable data only works insofar you're dealing with dumb logic and not everything is as simple as an HTTP request that returns rows of comments in a simple blog.
Also, I find an article bitching about OOP and about UNDO weird at best if it doesn't reference THE OOP recipe for undoing whatever you changed -- http://en.wikipedia.org/wiki/Command_pattern
The point about PHP is that it successfully does that precisely because the way it's architected. The state is kept the DB server where the transaction problem is solved.
When using long lived server processes, things tend to get in invariant states on error conditions unless you are very careful about how you are programming and dealing with state mutation and error condition. As ugly as it seems, PHP style development frees you from that.
I like your point about Chrome, it's a great architecture and it's actual quite similar original Apache PHP combo with the process isolation.
Anyway user level undo is still an important concept, but orthogonal to creating reliable software systems.
And I'm saying that having read it. Three times. I wish I'd taken bad_user's comment on face value but your comment and the author's comments made me read it.
Whole chapters were squirming before my eyes that seemed to make a single tiny point. Was I missing some gem of knowledge to unlock the shockingly badly written conclusion (otherwise known in writer circles as 'Um, what was I saying?')? Whole rambling diatribes could have been cut down to single sentences ('Building a Deck' and 'The Miracle Deck', I'm looking at you.). A little of my soul died inside. I thought I was missing something because he waffled so much.
I wasn't.
And 'I lost my interest at' perfectly sums it up.
This is an old article by someone who at the time wasn't a very good writer.
The core points of the article are sound, the author is right about programs being too brittle, but he took a lot of words to say it and his conclusion buried unconventionally in the middle of the article is way, way, way, way, way, way, way off the mark and the article is a massive chore to read. This is from 2006 and it shows.
Not really. I didn't see the author ever claim you could magically control external mutable state, indeed he explicitly acknowledged that:
> Unfortunately, adding the toolbar bar to the window may not truly be an atomic operation down deep, but from your perspective it is, since you can't make the mutation operation any smaller. You may not have completely eliminated the chance of things going into a bad state, but you've minimized it as far as you can.
He just says "do the best you can with your own software, and here are some ideas about it". It's an old article, appropriate for its time (detailed because many people were new to functional concepts) and yet surprisingly prescient (the rise of functional languages did occur). Nobody forced you to read it if you happen to be some whiz-functional programmer to whom all the points are intuitively obvious. Honestly, I don't understand the negative tone in many of the comments.
def servers := ( sort possible servers according to rules );
def sent_to;
send_attempt: for server in servers {
try {
server->send_mail_to( message );
sent_to := $server;
last send_attempt;
}
catch Temporary Failure {
logger->note_temporary_failure( ... )
}
}
if(!sent_to)
throw Permanent Failure ("EPIC FAIL");
Using error codes alone would be complicated ("if result_code == TRY_AGAIN_LATER then { try the other server } otherwise { return TOTALLY_FAILED_DUDE }"), and using exceptions without the "sent_to" state would also be quite complicated (I'm not really sure how to even do that).
The key is to use the features for what they're good at, rather than to treat them like an ideology.
From an ideology perspective, your language's designer already decided what he wants you to do. If you can accidentally ignore an error, you're using the wrong one.
That means in Java, you tend to favor exceptions, because you get some compile-time type checking to make sure you're handling them. And if you don't handle them, your program exits at runtime, which is a good thing. Return codes, on the other hand, are easy to ignore, and your program produces undefined results if you forget to check them (and no compiler is going to tell you where that is: you'd better have good tests, tolerant users, and no deadline).
In Haskell, on the other hand, the ideology is reversed. If you throw exceptions in IO, they basically work like exceptions in untyped languages -- your program exits unless you were lucky enough to have a runtime handler. (If you throw them outside of IO, like with "error", you're double fucked. You can't even catch them outside of IO, which basically means Never Do That.)
But the good news is, there are type-safe return codes. You define a type like:
data Either a b = Right a | Left b
And, of course, this is generally hidden from the programmer with monads! You don't even have to think about handling the return codes: the language does it for you.
(C is a weird case where both exceptions and error codes work poorly. For that reason, I make sure to write C in very tiny pieces that can be composed with a safer high-level language. In that case, there are only a few places where errors can occur, and they tend to be simple like "tried to allocate memory, it didn't work, so i deallocated everything else" or "failed to send to the socket: EAGAIN". The complex logic like "failed to send to primary MX" should be handled higher up in your stack.)
EOF and Apache Cayenne are ORMs that have a notion of a hierarchy of 'editing contexts'. If you save to the top-level one, it commits to the schema. But you can create a 'child editing context'. You can then interact with this graph. When you commit it, it gets pushed up to the parent editing context. Of course, if you want you can them commit again to persist it.
This allows you to build and throw out a deck.
This creates a new problem, a human one. People are used to interacting with web applications, and having everything saved somewhere after each screen change. With this arrangement, stuff doesn't necessarily get saved. I built an application that allowed you to create an order, and then create a person associated with it, and all this in memory. Users were annoyed that when they didn't save the order, the people they'd created associated with it also got thrown out.
I can imagine systems where you provide multiple implementations, and the system automatically finds one that works.
That's one way to do hi-rel processing in 'C'.... it all makes choice of language less of an issue. And if you have adequate logging of test site installs ( meaning all state transition data is logged ), then you can reproduce 100% of failures in a controlled environment.
It's not magic, but somehow, making the error cases explicit events has ( on me at least ) the effect of being able to reason about them more effectively. It's just another event.