i love just about everything that comes out of Joel, but this seems like a sacrilegious blasphemy.<p>Speaking from a strongly typed managed environment, exceptions are a special citizen that can get across many abstractions, and provide great flexibility in who/what/where should handle them. They are not meant to be used to communicate an outcome of some task/procedure. They are meant to signal that something catastrophic has happened and current function/task/process needs to handle it or end its existence.<p>Few examples: a stream gets closed by the other endpoint, database write fails, memory gets corrupt, or if you're a creator of an api and you want to signal to your future subscribers that something is missing i.e. they are trying to read data w/out opening a connection.<p>A lot of them can be avoided with some foresight (checking if a connection is open before calling a read, checking for null before calling methods on it, checking if enum is defined before casting to it), but not all can be avoided.<p>The beauty of exceptions is that they are decoupled from the rest of the code. You can put a listener at any level of abstraction, anywhere in your code.<p>return codes is what i'd expect from old school developers that still put their business logic in stored procedures. I suppose there are times where they are appropriate but in no way do they replace exceptions. (again, speaking from a object oriented environment)
FFS not again. Exceptions are more human friendly and provide more context than 102324323452. Even a NullPointerException explains more than that number.