Wez Furlong has a proposal for structured errors in PHP. I like the idea of standard error codes. I don’t much care for the exception_map or the superglobal part, though.

Even languages that have had exceptions forever still have controversy over the issue. Joel on Software considers exceptions harmful and favors status returns:

A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be. 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, and papering it over with exceptions does not make your program more robust.

Doug Ross agrees with Joel and talks a bit about poor software quality. It almost seems like he is elevating exceptions considered harmful into exceptions kill:

In other words, many of us are undisciplined. We’re more worried about “readability” (and I disagree with that contention as well – but I’ll get to that) than whether or not or software will kill anyone, debit the wrong account by a million bucks, or screw up the actuarial table for 83 year-old transvestites.

I agree with Ned Batchelder’s comprehensive rebuttal in exceptions vs status returns. Bob Balaban comments on this with an anecdote:

Years ago at Lotus one of the architects did an actual benchmark of some code in 123 written first with the status technique and then with the exception technique, and claimed that the exception technique was 15% less code (he was comparing compiled code size) and maybe 5% faster.

Following my API Design principles, I think the smallest amount of code wins. If exceptions can reduce the amount of code, then that is the best way to go. After all, error propagation code can have errors too. Code verbosity considered harmful.