How should a class library present a notification to the user/UI?

Question

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?

Answer 1

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.

Answer 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!

Answer 3

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".