4

Is it a good idea to send Exceptions as EventArgs in C#? (And not actually throw the Exception).

I have a class that performs a long running asynchronous task. If something goes wrong in the middle of the task, it will raise an Error event. Is it a good idea to add an Exception as part of the event arguments, or would it be better to use enums?

This class is just one of many that implement a certain interface. All classes in this interface raise the Error event when something goes wrong. Each class that implements this interface will run into different types of errors.

What are some of the best practices in a case such as this? Sending an Exception as an argument and not actually throwing it feels a bit wrong.

Improve this question
2
  • It really depends on what you mean by "asynchronous task." Is this task running on a separate thread? Also, I may be wrong, but I think the old BackgroundWorker class implements error handling in a similar way to what you suggest.
    – MetaFight
    Commented Sep 7, 2015 at 13:33
  • Yes. Running on a seperate thread. And yes, it does indeed: msdn.microsoft.com/en-us/library/…
    – Elie Steinbock
    Commented Sep 7, 2015 at 13:36

2 Answers 2

Reset to default
5

Is it a good idea to send Exceptions as EventArgs in C#?

Enh? It's not a great idea.

Is it a good idea to add an Exception as part of the event arguments, or would it be better to use enums?

If you have a fixed set of ways the long running task could fail, then the enum may make sense. Since you say that there are a number of implementers for this interface, you likely have an open set of ways it can fail, making the exception more palatable.

What are some of the best practices in a case such as this?

In general, I dislike events for this sort of thing. You're not guaranteed that anyone is listening. Since something has already gone wrong, it's kinda likely that one of your event handlers will go off the rails, interrupting the chain and/or throwing an exception in the handler, leading to problems.

I would look to see if you couldn't change that to more of a single error handler delegate, perhaps using abstract base classes to force it to be provided via constructor rather than added post construction (which you can't really guarantee at compile time).

That said, passing around exceptions is a little smelly, but not terrible in cases like this. I mean, you're catching an exception and asking a strategy to deal with it. Converting the exception to something else (with likely loss of information) seems to be unnecessary overhead/confusion.

Improve this answer
4
  • So the plan is actually to use a delegate for critical errors, passing in an exception as an argument, and events for non critical errors. The non critical errors will still receive an exception as an argument but will only be used to display info to the user really. Not to handle the exception in any way
    – Elie Steinbock
    Commented Sep 7, 2015 at 14:05
  • @EliezerSteinbock: Handling an exception can be that you just inform the user that an operation has encountered a problem. In that sense, the exceptions in your non-critical errors are being handled if you show some kind of feedback to the user.
    – Bart van Ingen Schenau
    Commented Sep 7, 2015 at 14:22
  • 1
    @EliezerSteinbock - users should (in general) not see exception information. That sort of info can provide insight to allow security breaches, leak personal information, and is decidedly off-putting to users. Also, they're not internationalized.
    – Telastyn
    Commented Sep 7, 2015 at 14:29
  • I didn't mean precise exception information. I meant some kind of notification that things didn't go 100 percent as planned in their language
    – Elie Steinbock
    Commented Sep 7, 2015 at 15:27
2

From a purely theoretical standpoint, (irrespective of the particular situation that you have at hand,) an event signifies a state transition of a system. Now, if an error occurs during the processing of a request, then ideally, the system should have a built-in rollback mechanism, so no state transition should occur, therefore, no event should be issued. If, nonetheless, a state transition does occur, then an event should of course be issued, but it should only contain information about the state transition. Error information does not fit into this picture; it is irrelevant. Observers of events expect to be notified about transitions so as to take appropriate action, they have no use and no interest in knowing anything whatsoever about errors.

Now, all that is completely unrelated to the response of a request. When a client sends a request, the server sends back a response to that client, and only to that one client. (Additionally, if the processing of the event results in a state change, then it will issue a state change event to all registered observers, but that's a different issue.) This response to the requesting client should, of course, contain error information in case of failure. The fact that you are using an event mechanism to implement your responses is completely irrelevant, and actually plays the role of a red herring in this discussion. So, including an actual exception object within a response seems perfectly legit to me.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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