3 ms·
C# went with properly typed but unchecked exceptions. IMO it gives you a clean error stacks without too much of an issue. I also think its a bit cleaner to ha
by jayd16 1y ago
C# went with properly typed but unchecked exceptions. IMO it gives you a clean error stacks without too much of an issue.
I also think its a bit cleaner to have a nicely pattern matched handler blocks than bespoke handling at every level. That said, if unwrapped error results have a robust layout then its probably pretty equivalent.
- pjmlp 1y agoUntil routinely prod goes down with that exception that no one cared to handle, been there done that.
- jayd16 1y agoFor something like a web request, all the frameworks catch the exception at the request level. Prod should not be going down. Maybe you mean requests are failing on uncaught exceptions, in which case I'd say it's working well.
- pjmlp 1y agoFor the customer there is hardly any difference that the server keeps running if a critical workflow, especially with a payment in flight, crashes and burns. Or if they are unable to work, because they keep getting a maintenance page, as the load balancer redirects them after several HTTP 500 responses.
- jayd16 1y agoThere're a huge different between a broken feature and the whole server crashing every time that feature is attempted. Anyway, you prefer critical workflow like payment to show a success but actually be an unhandled error?
- pjmlp 1y agoFor the customer the difference hardly matters, they cannot fulfill what they intended to do, because someone somewhere forgot to catch an exception, going all the way out of the MVC controller, providing a very bad UI/UX, and from security point of view, a possible DOS attack vector. I prefer an happy customer, and not having to deal with support calls.
- deleted 1y ago[deleted]