Exception handling use cases

[HunteRoi]

Context: Imagine you want to read a file's properties from an API (because the file is stored in the cloud).
Use case: ReadFileProperties

Would you handle unhappy flows in your use case handler or outside of it?

Possible unhappy flows:

• the file does not exist
• you don't have the permission to read the properties
• unknown error or anything else that might be the developers' fault

Happy flow (use case): you retrieve the properties of the file and return them to the caller

___
I have been poking around this topic for a little bit now, but I can't quite get to decide if I want to remove my unhappy flow management from the use case into a dedicated handler or not.
What's your opinion?

[valentinajemuovic]

I throw exceptions. The following are places where I throw exceptions:

1. Domain layer - throwing exceptions from domain entities, value objects if some invariant has been violated (e.g. price is negative)
2. Application layer - throwing exceptions from use cases if it can't be executed (e.g. the we can't execute SubmitOrderUseCase if the order returned by the repository is null)
3. Infrastructure layer - let's say I'm calling some external API and it's returning invalid data, or error codes, etc.

So then I throw the exceptions from anywhere, but then I have a centralized exception handler. So I don't do catching in the use case by in the global exception handler. I use the global exception handler to convert the exceptions into whatever form is required by the presentation layer.

[apurcaroiu]

Hi @valentinacupac ,

Where I struggle a little bit is at case 2 that you described, for more complex scenarios. What if the requirement is to send a notification to some business group that the order could not be placed, so basically if the repository returns null for SubmitOrderUseCase, you need to handle this with another business step.

I am not sure where this would be handled, either the use case will handle the result and execute the other business step, or would this be handled in the data layer directly or maybe have two separate use cases and have a facade that orchestrates this entire business flow by composing the two use cases.

I feel I alway struggle to identify what would be the most clean way of doing it.

Great community here and with great topics :)

[PCreations]

You can Indeed go all in with Exceptions as Valentina said. Another option is to use some kind of "Result" wrapper that wraps the response or the error. You'll have to handle it in the use case, without having to catch exception and thus inverse the flow of control. But is has downsides too, in language where there is no algebraic data type integrated it can be a bit verbose to just unwrap a value.
If you want to go this way you can search for "Either monad".

[HunteRoi]

What about several specific exceptions handlers?

Let's say you have a use case. It might throw 2 specific exceptions and each exception requires a specific flow management. Of course you could have a generic exception handler but that would mean handling a lot of possible exceptions in it.

Would you say it's a good idea to handle your specific exceptions in dedicated handlers for that specific use case and in case you have unhandled exceptions you fallback on a generic exception handler?

[valentinajemuovic]

@PCreations thanks for mentioning that. Yes, the two approaches boild down to:

• Either the exception is thrown from the "core" (from the domain or use case), and then it's caught at the presentation layer
• Or, the use case catches the exception so the use case returns a result wrapper, which would typically have success boolean (succeeded/failed) and then an object for successful result vs failed result

@HunteRoi interesting remark. Do you have an example where each exception requires a specific flow management? If you have any sample repo on your GitHub, feel free to link here. I'm interested to see this situation, as I may consider it in expanding the Banking Kata...

[HunteRoi]

I don't right now but I can look into it. I only considered this option because at work I use RequestHandler and RequestExceptionHandler from MediatR. Our use case is simple: I need to process xml files and in case of error, I have to trigger the error management which consists of generating a .err file in a specific folder and copying the xml file in the same folder.

As this is currently the only use case, but the app is subject to expansion, I considered that the error management flow is only related to this particular use case (at least I haven't been told otherwise). I still have a global exception handler for all use cases but it is not used so far as my single use case is covered by its exception handler.

[marciovmartins]

If you are working in a OO paradigm, the exception from the core domain and application are expected. The invariants or some infrastructure problem occur and the process should be aborted. Otherwise probably your use case is doing more than expected.

Probably you would have one use case doing the job of two, and this should be split and the controller/command line/input should call two use cases.

Otherwise it is like use the java Optional class everywhere.