> Exceptions represent programmer error; error codes represent user error. No, they represent whatever suits the system design and the house style. They're ju

> Exceptions represent programmer error; error codes represent user error. No, they represent whatever suits the system design and the house style. They're just tools to pass data and manipulate control flow. If you become dogmatic and start insisting on what they must absolutely represent, you're only going to find yourself compromising design coherence and futily railing at colleagues when different representations are found to be appropriate. With exceptions, it often makes sense to use them when failures inevitably just propogate up through a stack of nested calls or may appear anywhere in a sequence of calls. In these cases, return codes can grossly interfere with legibility and can lead to confusion when interim handlers squelch errors that really should have propogates up directly. These are the kind of choices that are completely reasonable to make within a specific module (like an auth and accounts module), and you can always return to some other default policy at the interface of that module if your project/house-style needs such. Engineering shouldn't feel so dogmatic as you suggest. It's a strong smell when it does.