3 ms·

My issue with that is that absolutely NOTHING will ever convince me that returning error codes is a better idea than throwing exceptions. And that you seem to b

My issue with that is that absolutely NOTHING will ever convince me that returning error codes is a better idea than throwing exceptions. And that you seem to be using 'expected' in some weird cargo-culty sense of the word. An invalid user name is an error, not an expected case.

nip 2y ago
I’ll try: Returning a “Result” with union discrimination on the “success” is far superior to throwing in Typescript in my experience { success: false, reason: “user_already_exists” } | { success: true, data: { user_id: string } - By design you are forced to “deal” with the sad path: in order to get to the data, you must handle the error state - Throwing is not type-safe: you cannot know at build time whether you are handling all thrown errors
yellowapple 2y ago
> An invalid user name is an error, not an expected case. If you ain't expecting users to input bogus data, then you're putting way too much trust in said users. Put simply: is it a bug in your own code if a user tries to use an invalid username? If yes, then throw an exception. If no, then return an error code. Exceptions represent programmer error; error codes represent user error.
- swatcoder 2y ago
  > 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.

nip 2y ago

I’ll try: Returning a “Result” with union discrimination on the “success” is far superior to throwing in Typescript in my experience { success: false, reason: “user_already_exists” } | { success: true, data: { user_id: string } - By design you are forced to “deal” with the sad path: in order to get to the data, you must handle the error state - Throwing is not type-safe: you cannot know at build time whether you are handling all thrown errors

yellowapple 2y ago

> An invalid user name is an error, not an expected case. If you ain't expecting users to input bogus data, then you're putting way too much trust in said users. Put simply: is it a bug in your own code if a user tries to use an invalid username? If yes, then throw an exception. If no, then return an error code. Exceptions represent programmer error; error codes represent user error.

swatcoder 2y ago
> 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.