Timeline for Communicating unpredicted Failure from Repository implementation to Applicaiton Layer
Current License: CC BY-SA 4.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 21, 2023 at 14:04 | comment | added | incongruentDoughnut | Right on. So, w/ Errors vs. Exceptions aside and I think it's a given you understand that the Exception is designed against the interface, not the implementation, so next is to consider how a consumer recovers from that Exception. ex: Did the exception arise from a network connectivity issue or an authorization issue? Those are things the consumer might be able to recover from (backoff strats or login redirects), so maybe we need a 'NetworkFailureException' or 'AuthorizationException' or just an 'ErrorId' prop. The other thing to consider is how those exceptions appear in logging. | |
| Jul 19, 2023 at 19:04 | comment | added | John Hall | I agree with you particularly on saving Exceptions for Exceptional circumstances, which I did try to communicate in my question i.e., handling unpredicted failure which is IMO exceptional behavior. I appreciate the response though I do not feel it answers my question of how to communicate exceptional circumstances from a Domain-layer component (the repository contract) without making the client code (e.g., application service) privy to the technical implementation. Are you suggesting that my domain-layer CouldNotSaveException accomplishes this? I agree w/YAGNI and general exceptions during dev | |
| Jul 18, 2023 at 20:50 | history | answered | incongruentDoughnut | CC BY-SA 4.0 |