Mark exception as handled, rethrow, display

Question

Inside my business logic, I have something like a pipeline with multiple actions. Each action wrapped into try/catch and can handle exceptions by himself (logging, saving state for retry ex). And I have global exception handlers who also log all exceptions, can retry the operation and returns details to a client if it is possible. Like:

if (exception is ICustomException) return exception.Message;
else return "Something wrong";

Such exceptions like validation exceptions, pipeline action exceptions should not be logged and processed in global exceptions handlers.

Can I do something like

catch(Exception ex)
{
    ... 
    throw new CustomException() { IsHandled = true, Message = ex.Message}
}

or

exception.Data["handled"] = true;

to avoid double logging etc?

Is my architecture good enough in overall?

Answer 1

I think you're conflating two different things here.

The first thing is Structured Exception Handling.

This is all about, when something goes wrong, the code going in search of something that can deal with it (i.e. an Exception Handler). That handler will either "handle" the Exception completely, causing it to be resolved and, therefore, making it "go away" or it will throw the Exception (or a related one) again, in an attempt to find something else that can deal with it.
Typically, your "global" Exception Handler is only a "backstop" that catches everything, makes sure it's safely recorded for later diagnostic work and then lets the process crash and burn.

So, your idea of marking whether an Exception has been "handled" or not is not really valid. Either an Exception Handler deals with the Exception or it passes it along to something else.

Where I have seen this principle is in Event propagation, where one, raised, Event can be passed around many subscribers and each needs to know whether whether or not the Event is still "Live".

The second thing is the handling of Errors in your pipeline processing.

It seems to me that any stage in your pipeline can go wrong and you have a mechanism to detect this and "park" the item for reprocessing later. That's a really good thing, but it's not Structured Exception Handling, in itself. Sure, you can (and should) use S.E.H. to initially detect the problems and route the items accordingly, but the Handlers of these Exceptions should "consume" (i.e. not rethrow) such Exceptions, so that the global Exception Handler never sees them.