Dealing with exception handling from ViewModelAppenders inside a composition

[Stephanvs]

Hi Mauro,

We currently have a similar implementation of a ViewModel composition engine in our project. We're considering migrating to this libarary (just fyi 😉).

I was thinking about exception handling in a composition. Let's say a handful of services contribute to the composition of a complete page. If a single ViewModelAppender in the current implementation throws an exception, the whole composition 'fails' and returns an error status code/response, and we're unable to show anything to the end-user. At that moment we should retry the request or resort another alternative.

Some services only contribute a small feature, which might not be considered 'critical' or even important to show in the UI. We could easily just not show them if they failed.

What do you think about wrapping each ViewModelAppender's Append method with a try/catch block. For instance; in this line
https://github.com/ServiceComposer/ServiceComposer.AspNetCore/blob/master/src/ServiceComposer.AspNetCore/CompositionHandler.cs#L146

Or do you have a strong reason not to do this specifically and have exceptions handled by the Appender itself?

I'm curious what you think about this and am looking forward to a response.

Regards,
Stephan

[mauroservienti]

Thanks for your question @Stephanvs and I'm happy that you're thinking about using ServiceComposer.

I spent a lot thinking about exception handling and less important handlers and I couldn't find a solution that satisfied me without compromising on something. I'm leaning toward thinking that it's not ServiceComposer composer responsibility to deal with errors in handlers.

Let me give you an overview of the whys:

• ServiceComposer composer has a generic ICompositionErrorsHandler mechanism that allows code to hook into error handling, and intentionally doesn't allow for error suppression, it's just a way to provide handlers with a chance to recover. This is primarily designed with write scenarios in mind and not read ones.
• If ServiceComposer was to handle exceptions for each handler it would also require a mechanism to let handlers explain if the error should bubble up or not, otherwise the only option would be to suppress any error which is not ideal.

Given that your code is the best place to understand if an error should bubble up or not, I have always preferred to have try/catch blocks in handlers where appropriate, instead of a generic mechanism to handle failing handlers.

That being said. Change my mind! 😎😀