5 ms·
It's all tradeoffs. For me, not having to deal with passing state past a trailing try/catch clause and not worrying about errors potentially bubbling out of one
by macrael 4y ago
It's all tradeoffs. For me, not having to deal with passing state past a trailing try/catch clause and not worrying about errors potentially bubbling out of one layer into another are worth the extra "if (res instanceof Error) { return res }" lines
- Aeolun 4y ago> not worrying about errors potentially bubbling out of one layer into another I feel like that’s the entire point of errors and try/catch?
- macrael 4y agoThe trouble with throwing is that the compiler doesn't care if you catch. For any library that throws, I wrap that up in my adaptor layer with try catch and then return an Error upwards. That way in the rest of my domain I've got the compiler complaining if I'm not handling an error that is coming from below. I can be sure that when I'm handling an error it's not going to be something random from 2 layers down, because it was explicitly returned by the layer I'm calling. As in most things coding, you can accomplish the same thing with either approach, but I believe by returning an `| Error` there's a better chance for the compiler to catch a bug before I run the code.
- Aeolun 4y agoThat’s true. It’d be nice to mark methods as throwing some error and requiring it to be caught at some point (I believe Java does this). But I can imagine it might be a bit hard in Typescript due to the async nature.
- hot_gril 4y agoIt's like this in Java, but at that point I'd rather do the | Error return type. Same level of explicitness either way.