5

Something occurs that is more or less expected with normal use of a .NET library you are writing. You need to notify the user/UI/caller that this event has occurred, even though it is expected and not exceptional. Do you:

A) Throw an exception, let the UI catch it and deal with it.

B) Raise some type of event that the UI can listen for.

C) Do something else

Which of the above do you do? If both, what are your guidelines for when to throw an exception vs. raise an event? What are the pros and cons of each?

Edit:

Here is an example I'm facing. My library uses a third party application to print shipping labels by starting the third party application and passing an XML file as an argument, which is processed as a batch type operation. If the third party application is already open by a user, it must be shut down before my library can call it for the batch operation. My library checks to see if the application is running, and if it is, it simply stops and needs to notify the user that they should close the third party application and try again. I fully expect this to happen as part of the normal use of the library. Throw an exception, or raise an event?

Casey Wilkins
  • 2,555
  • 2
  • 23
  • 31
  • Per your edited example, I would throw an exception, since it sounds like your class can't proceed until the situation is resolved. Think of it as a file is locked and you are trying to write to it-- you get an exception. – LarsTech Jun 10 '11 at 22:12

6 Answers6

4

This certainly sounds like something where an event is the most appropriate approach. Unless you've got a method which can't fulfil its main purpose, I can't see why an exception would be the right way of doing things.

In general "notification" should suggest an event...

If you can give more examples of the kind of situation you're thinking of - particularly any where you would lean towards an exception - we may be able to help more.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Thanks. I left an example above. To be honest I rarely find a situation where throwing an exception feels right. For the above example I'm thinking of making one static event for each library that is responsible for notifications. Would that be a reasonable approach? – Casey Wilkins Jun 10 '11 at 22:02
  • @Casey: No, that doesn't sound right - there should probably be one (instance) event type of notification, within each component. – Jon Skeet Jun 11 '11 at 07:12
  • Would you consider the example an event or an exception? – Casey Wilkins Jun 11 '11 at 13:14
  • @Casey: That sounds more like an exception, to be honest. It's pretty unusual though. – Jon Skeet Jun 11 '11 at 14:32
2

Exceptions are different from events because you have to handle them.

If you think the client code just can't go on, throw an exception (examples: network error, security error, bad input). Otherwise, kindly acknowledge that something has happened by raising an event but don't force the caller to react immediately.

Also note that events may be raised and handled asynchronously and are not bound to particular caller's actions, whereas exceptions always get thrown in context of a specific method call. Of course, you can throw exceptions from anywhere but if the client code doesn't expect them where they occur, they become essentially useless because unhandled.

See also this thread.

As for your situation:

Apparently, in your case workflow cannot continue unless the third-party application is closed, and this situation is not exactly normal, meaning it's more of a technical restriction than a true workflow option. You also can't let the client code just ignore it. This fits exceptions immediate-response nature.

However, it is also true that this situation is not all-exceptional because on some level it is known and expected.

Because of that, I suggest you do this:

  • introduce a CanRunNow property that determines if application is running;
  • check this property in client code prior to calling Run method (let's assume it's called so);
  • in Run method, do the check again, and if this time CanRunNow is false, throw an exception (now this is unexpected!)

This way you give the client code freedom and responsibility to either do a check and stay safe, or to go right ahead (and possibly get an exception). Whatever behavior you choose, make sure to document it!

Community
  • 1
  • 1
Dan Abramov
  • 264,556
  • 84
  • 409
  • 511
1

If its expected, then it's an event. If it's not expected, it's an exception.

Just don't let "C" be "showing a message box".

LarsTech
  • 80,625
  • 14
  • 153
  • 225
0

You say the event is expected (that is, is not exceptional) so therefore, I think you have answered your own question... Definitely B in my opinion.

Reddog
  • 15,219
  • 3
  • 51
  • 63
0

There are 2 things you want to notify, custom events and error handling.

Im agree with the other answers, catch the exception, and delegate it, as an event, to the G.U.I.

umlcat
  • 4,091
  • 3
  • 19
  • 29
0

In my applications I use an interface which contains methods for communication with user.

Somthing like: 

interface IErrorAndStatusReporter {
   void ReportStatus(string message);
   void ReportError(Exception err, string message);
   ...
}

The top level system passes an instance of this into the classes/methods that needs it.

The benefit is that I can decouple the reporting from the implementation of the logic. The code is easier to test and reuse. The reporting is implemented in different ways depending on the environment:

  • GUI Application : open dialog or show in some error list
  • Console application : write to console
  • Windows Service : log to eventlog and send email
adrianm
  • 14,468
  • 5
  • 55
  • 102