0

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?

  • I don't understand why you want to rethrow a handled exception in the first place. Maybe you can give a little bit more detail how these exceptions are used. – Helena Oct 7 at 15:46
  • 2
    You want to log the exception and then mark it (so it isn't logged again), and then rethrow because it isn't actually handled and you cannot resume execution in the intermediate handler? First don't use the name IsHandled, use IsLogged instead. Second, don't bother catching it in the intermediate places at all, and log it centrally. – Erik Eidt Oct 7 at 16:06
  • Please don't use exceptions to drive business logic. – Jon Raynor Oct 7 at 18:14
3

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.