0

Several posts cover the issue of providing user-friendly messages based on catched exceptions, like Report exception message

I am also of the opinion to wrap exceptions of a lower layer to a defined exception of the current layer to ensure encapsulation. For example a service or domain layer should not expose exceptions from data access layer.

In my UI layer I catch the exceptions defined in service or domain layer and transform them to meaningful user messages in dialogs. I do not use the exception message because it might 1) not be user-friendly and 2) not be internationalized.

Now I am developing a mobile app the first time. I find it useful and Importamt for the users to show them an appropriate message if an action cannot be executed because of connection or network issues (maybe bad or no service or in flight mode etc.)

To show this kind of message I must catch it from the service/domain layer to transform to a user-friendly message and do internationalization etc. But this seams counterintuitive to me to expose these kind of exceptions in this layer.

So is it okay to have NetworkException exposed in domain layer in a mobile app? Or are there any other techniques to handle this scenario? I feel a bit bad about this because it introduces a leaky abstraction, but I have no idea how else to get information on these low level exceptions that are important for users.

Or am I on the wrong path and it is quite okay to tell the user "Operation x cannot be executed", without giving any reason?

Update:

Eric Evans shows this diagram in his DDD book:

DDD Layered Architecture

There is a connection from UI layer to infrastructure layer. Can this be interpreted as the UI may be aware directly of Infrastructure exceptions?

Creepin
  • 482
  • 4
  • 20

1 Answers1

0

Your domain should not be throwing any exceptions because of the reasons that you have listed and more. Exceptions are inevitable though, so it should be handled gracefully within the boundary of your domain but should not get out.

For controlled exceptions like 404 from a dependent API or the user data validation failure, you want to return meaningful data like a nullobject or just an domainspecific error object. This also applies to exceptions like network exceptions. Your method should gracefully handle the exception and your domain should return an object that fits the UL

Louis
  • 1,194
  • 1
  • 10
  • 15
  • Can follow you and agree that the domain should handle domain exceptions internally. But my confusion resides. In my opinion in this case the UI layer must be aware of an infrastructure exception, the network exception, to show a meaningful message. But I don't think that the domain should expose the network exception, neither as a real exception nor as a return object since the network is not part of the domain. So should the infrastructure exception just cross the domain layer uncatched / unwrapped and the UI layer is aware of this exception and hence needs a reference to the infrastructure? – Creepin Mar 06 '18 at 08:13
  • The network is not part of the domain but the domain is the only consumer of the network calls (I am assuming here - unless you are talking of front end network calls but I doubt that since we are talking DDD). My assumption therefore is that the domain's action triggering the network call will be aware of it's failure and can transform that failure into a proper object. – Louis Mar 06 '18 at 13:57