Error States
-
It's easy enough to throw an exception from a method in a class you've written when the preconditions of the method haven't been met. You can do so while maintaining the class's invariants. It's harder, though, handling an exception thrown in the middle of the method from a source outside your control, say from an object you've invoked a method on. Enforcing a class's invariants is trickier here. One approach is to treat the exception as an event. When it occurs, you have code in place that transitions your object to a state appropriate to the exception thrown, i.e. some kind of error state. The question then becomes how should the object behave in an error state? Are there steps to be taken to bring the object back to a useable state? If so, what are they? I'll give an example. I have a
Synthesizerclass in my C# Synth Toolkit. It's capable of recording the waveform output as it is synthesized and writing it to a wave file. This takes place on thread other than the main one. Let's say that an IO exception of some sort happens when attempting to write the waveform data to file. The exception is caught. Now what? I was thinking that it would be appropriate to raise an event on the main thread notifying the user that an error occurred. In addition, theSynthesizerwould transition back to a non-recording state. TheSynthesizerwould continue to function normally. Another situation has me a bit stumped, though. TheSynthesizeruses anOutputDeviceclass for playing waveform data. If theOutputDeviceobject being used throws an exception, it's pretty much a show stopper. There's not much theSynthesizercan do if it'sOutputDeviceisn't useable. So I was thinking that in this situation, an error state would be appropriate. In this state, some of its methods would throw anInvalidOperationException; they just can't be performed if theOutputDeviceisn't working correctly. Other operations might be allowed in order to reset theOutputDeviceto get it working or use a different one. I guess what I'm getting at here is that I'm wondering how you deal with exceptions when they pretty much render an object unuseable. -
It's easy enough to throw an exception from a method in a class you've written when the preconditions of the method haven't been met. You can do so while maintaining the class's invariants. It's harder, though, handling an exception thrown in the middle of the method from a source outside your control, say from an object you've invoked a method on. Enforcing a class's invariants is trickier here. One approach is to treat the exception as an event. When it occurs, you have code in place that transitions your object to a state appropriate to the exception thrown, i.e. some kind of error state. The question then becomes how should the object behave in an error state? Are there steps to be taken to bring the object back to a useable state? If so, what are they? I'll give an example. I have a
Synthesizerclass in my C# Synth Toolkit. It's capable of recording the waveform output as it is synthesized and writing it to a wave file. This takes place on thread other than the main one. Let's say that an IO exception of some sort happens when attempting to write the waveform data to file. The exception is caught. Now what? I was thinking that it would be appropriate to raise an event on the main thread notifying the user that an error occurred. In addition, theSynthesizerwould transition back to a non-recording state. TheSynthesizerwould continue to function normally. Another situation has me a bit stumped, though. TheSynthesizeruses anOutputDeviceclass for playing waveform data. If theOutputDeviceobject being used throws an exception, it's pretty much a show stopper. There's not much theSynthesizercan do if it'sOutputDeviceisn't useable. So I was thinking that in this situation, an error state would be appropriate. In this state, some of its methods would throw anInvalidOperationException; they just can't be performed if theOutputDeviceisn't working correctly. Other operations might be allowed in order to reset theOutputDeviceto get it working or use a different one. I guess what I'm getting at here is that I'm wondering how you deal with exceptions when they pretty much render an object unuseable.Hi Leslie, I see an analogy with a file system and a "disk full" situation. The .NET Framework does not do anything special under "disk full" situations; you may have created a file, and be happily wiriting to it, suddenly it throws an exception at you. If you happen to be on a separate thread, you would use some mechanism (an event probably) to signal it back to the requestor )e.g. the GUI). The File class does not handle events, but it does not launch separate threads eiher; they leave it open to the user to make such choices if and when required. if you do create a thread, obviously it may encounter a problem and I think you should indeed include an event mechanism to signal those. Hope this helps.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/AllLanguages/General - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
Hi Leslie, I see an analogy with a file system and a "disk full" situation. The .NET Framework does not do anything special under "disk full" situations; you may have created a file, and be happily wiriting to it, suddenly it throws an exception at you. If you happen to be on a separate thread, you would use some mechanism (an event probably) to signal it back to the requestor )e.g. the GUI). The File class does not handle events, but it does not launch separate threads eiher; they leave it open to the user to make such choices if and when required. if you do create a thread, obviously it may encounter a problem and I think you should indeed include an event mechanism to signal those. Hope this helps.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/AllLanguages/General - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
Luc Pattyn wrote:
The File class does not handle events, but it does not launch separate threads eiher; they leave it open to the user to make such choices if and when required. if you do create a thread, obviously it may encounter a problem and I think you should indeed include an event mechanism to signal those.
I was thinking about having an
Errorevent that is raised when an exceptional situations happen on a thread other than the main one. The event will be marshaled to the main thread by using theSynchronizationContextclass. However, last night I did some research, particularly looking at Java's checked and unchecked exceptions. A best practises tutorial suggested that you should catch exceptions you can recover from but not those you cannot. Seems like common sense. So in those situations in which I can devise a strategy for recovering from an exception, I should catch it and deal with it. But there seems to be a class of exceptional situations in which there's not much that can be done. In those cases, the exception should not, according to the tutorial I was reading last night, be caught. I'm a little fuzzy on what happens to unhandled exceptions. I suppose there should be a strategy at the top level for dealing with them, notifying the user, and possibly shutting down the application. -
Luc Pattyn wrote:
The File class does not handle events, but it does not launch separate threads eiher; they leave it open to the user to make such choices if and when required. if you do create a thread, obviously it may encounter a problem and I think you should indeed include an event mechanism to signal those.
I was thinking about having an
Errorevent that is raised when an exceptional situations happen on a thread other than the main one. The event will be marshaled to the main thread by using theSynchronizationContextclass. However, last night I did some research, particularly looking at Java's checked and unchecked exceptions. A best practises tutorial suggested that you should catch exceptions you can recover from but not those you cannot. Seems like common sense. So in those situations in which I can devise a strategy for recovering from an exception, I should catch it and deal with it. But there seems to be a class of exceptional situations in which there's not much that can be done. In those cases, the exception should not, according to the tutorial I was reading last night, be caught. I'm a little fuzzy on what happens to unhandled exceptions. I suppose there should be a strategy at the top level for dealing with them, notifying the user, and possibly shutting down the application.Yes, I think along similar lines. Some more remarks: 1. you are allowed to catch Exceptions to your hearts content, but not to hide them: i.e. you should remedy the problem or somehow let it ripple upwards. There are three ways to do that: - not catching the exception at all; - rethrowing the same exception (a simple "throw;" does that); - and the favorite: throw a new exception, more specific to your class or method, that holds the original exception as an "inner Exception". 2. Your background thread probably already has a Done event, thru which it reports results; you could use that same event to report problems, so there may not be a need to add another event. 3. there are situations where exceptions are more difficult to catch, such as in a constructor, on a thread you have no control over (say a timer tick), in native code, ... . The framework has some provisions to catch and handle these too, but I haven't grasped it completely yet. Things related to this are: - having try-catch in static Main(); I recommend this, it helps during development, especially is you show its entire ToString() as one always should. - AppDomain.CurrentDomain.UnhandledException - Forms.Application.ThreadException Greetings,
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/AllLanguages/General - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google