3 ms·
> You can't because you don't know where it came from Maybe that's a particular language constraint? In general exceptions have a stack trace and it's evident
by cptskippy 7y ago
> You can't because you don't know where it came from
Maybe that's a particular language constraint? In general exceptions have a stack trace and it's evident where an exception came from.
At least in my experience exceptions don't have to be handled unless or until they're disruptive. If you have a scheduler or task processor code that needs to run continuously then you're going to have robust exception handling, but not necessarily comprehensive or appropriate. For other areas of code however the exception handling isn't necessarily requisite.
- nicoburns 7y agoMy problem with exceptions, is it's generally not possible to tell which exceptions a given function might throw (especially problematic with nested dependencies). Thus even if there was a condition hat you could handle you might not know it was possible (until you hit the bug in production!) Result/Maybe types are awesome, because you just don't get unexpected runtime exceptions due to programming error. You only get them when a genuine problem occurs.
- cptskippy 7y ago> it's generally not possible to tell which exceptions a given function might throw That's a valid concern. I've seen attempts to document the custom exception types that classes can throw but it's never discoverable. It's compounded by the fact that uncaught exceptions bubble up. I don't know that most people would sift through all the possible exceptions and write selective catch blocks to handle them. I think in general they will either catch all exceptions or none, if or until they need to handle a specific scenario that presents itself in production. My perspective though is primarily of LOB Apps or Integrations and not widely consumed public code or apps.