For my work, I usually catch general exceptions and handle their aftermath, like putting the error in an error queue to be manually fixed and replayed or showin

For my work, I usually catch general exceptions and handle their aftermath, like putting the error in an error queue to be manually fixed and replayed or showing an error page. While there are domains like power plants or car software where every error must be meticulously handled, my approach suits my domain. When I see code making me catch numerous unique exceptions, it often hints at an API design issue. A more refined design might encapsulate such information in a response, maybe through a discriminated union or an enum with a message. If I can, I'd refactor it to match this ideal. If not, I'd use adapters to convert diverse exceptions into standardized errors. Exceptions should be exceptional: situations like memory shortages, database disconnects, or accessing a disposed resource. For these unforeseen events, control flow is typically the same as they're unexpected and beyond my control.