I have a fairly extensive question about programming that I was hoping someone could answer, or at least point me in the right direction to begin further research.
I'm writing a program in C# which interacts with a user and a source of information. During the program's execution, there are various loops (waiting for and processing user interactions and data changes). At any point during this, though, the data source can have an error (unstable connection to the data).
If this error occurs, I need to pause execution, note the error (and inform the user), then have the program 'go back to the beginning' of it's execution (before the error occurred).
The way I'm doing this now is rather inelegant.
During every loop in the program (and before and after all related functions), it calls a method which checks for a variable (_stop). There is another thread running which monitors the data source, and if an error occurs, it sets _stop = true.
So, if the method sees _stop == true, it sends back 'false', which begins a cascade of 'return false;' through all methods until the program is back at the original loop. It can then wait for the data to become available and resume functioning.
I feel like there must be a more simple and elegant solution to the problem than constantly calling a method to see if it returns false and then returning false all the way through all my loops, but I don't know what it might be (or how to research the problem further).
Do you have any advice for me?
Unexpected Error Handling
Page 1 of 16 Replies - 933 Views - Last Post: 09 November 2012 - 12:27 AM
Replies To: Unexpected Error Handling
#2
Re: Unexpected Error Handling
Posted 08 November 2012 - 01:59 AM
#3
Re: Unexpected Error Handling
Posted 08 November 2012 - 02:05 AM
MrShoes, on 08 November 2012 - 01:59 AM, said:
Thank you for the fast response.
I'm already using events (it's what the watcher is using to signal the main program with the _stop variable). So, I have that already in place.
During the main loops, I have to check that variable all the time to see if it has been set TRUE. Is there another way? Or should each loop/method set be in it's own class with it's own `_stop`-style variable?
-T
#4
Re: Unexpected Error Handling
Posted 08 November 2012 - 08:56 AM
The idea of events is that you don't have to check if a variable has been changed: you raise the event when it's change, and a subscriber performs actions when the event occurs. Something like this:
Worker class raises event if failed....
Manager responds...
The Manager is not checking if the Worker has failed. He's notified via the event being raised.
Worker class raises event if failed....
public class Worker
{
private bool failed;
public event EventHandler WorkFailed;
private void DoWork()
{
if(failed)
{
if (WorkFailed != null)
WorkFailed(this, EventArgs.Empty);
}
}
}
Manager responds...
class Manager
{
private Worker worker;
public Manager()
{
worker.WorkFailed += RespondToFailure;
}
private void RespondToFailure(object sender, EventArgs e)
{
//Response here.
}
}
The Manager is not checking if the Worker has failed. He's notified via the event being raised.
#5
Re: Unexpected Error Handling
Posted 08 November 2012 - 10:57 PM
MrShoes, on 08 November 2012 - 08:56 AM, said:
The idea of events is that you don't have to check if a variable has been changed: you raise the event when it's change, and a subscriber performs actions when the event occurs. Something like this:
Worker class raises event if failed....
Worker class raises event if failed....
public class Worker
{
private bool failed;
public event EventHandler WorkFailed;
private void DoWork()
{
if(failed)
{
if (WorkFailed != null)
WorkFailed(this, EventArgs.Empty);
}
}
}
Okay, this looks just like my Worker that's watching for the data to become unavailable. So, that much I'm following.
MrShoes, on 08 November 2012 - 08:56 AM, said:
Manager responds...
The Manager is not checking if the Worker has failed. He's notified via the event being raised.
class Manager
{
private Worker worker;
public Manager()
{
worker.WorkFailed += RespondToFailure;
}
private void RespondToFailure(object sender, EventArgs e)
{
//Response here.
}
}
The Manager is not checking if the Worker has failed. He's notified via the event being raised.
Okay, here's where I'm stuck. This worker is running a fairly-large loop. (Pseudo-code below)
while(!_stop)
{
Maintenance();
bool result = CheckForUserInput();
if (result)
{
DealWithUser();
}
}
So, the actual Maintenance(), CheckForUserInput(), and DealWithUser() methods are themselves large loops (similar design) that are also checking various inputs and data source. So, in that code, the only place I check for _stop is at the beginning, which is too infrequently.
I can then also have each sub-loop look for _stop.
With your example, how would the linked event method stop those inner loops and methods?
Thanks again,
-T
#6
Re: Unexpected Error Handling
Posted 08 November 2012 - 11:53 PM
From here, I'd look in each of those methods, and within the loops in each, if the conditions for "Stop" or "Fail" are met, then raise the event.
You can have a generic "Failed" event handler meaning the Worker class can raise the "Failed" event for whichever reason it's failed. The Manager can just respond to a basic "Fail" without knowing what type of failure it is (unless you do want to specify it, in which case you could have custom EventArgs).
You can have a generic "Failed" event handler meaning the Worker class can raise the "Failed" event for whichever reason it's failed. The Manager can just respond to a basic "Fail" without knowing what type of failure it is (unless you do want to specify it, in which case you could have custom EventArgs).
#7
Re: Unexpected Error Handling
Posted 09 November 2012 - 12:27 AM
MrShoes, on 08 November 2012 - 11:53 PM, said:
From here, I'd look in each of those methods, and within the loops in each, if the conditions for "Stop" or "Fail" are met, then raise the event.
You can have a generic "Failed" event handler meaning the Worker class can raise the "Failed" event for whichever reason it's failed. The Manager can just respond to a basic "Fail" without knowing what type of failure it is (unless you do want to specify it, in which case you could have custom EventArgs).
You can have a generic "Failed" event handler meaning the Worker class can raise the "Failed" event for whichever reason it's failed. The Manager can just respond to a basic "Fail" without knowing what type of failure it is (unless you do want to specify it, in which case you could have custom EventArgs).
Excellent. That should help with failure logging and such.
Thank you again for all your help, much appreciated.
-T
Page 1 of 1

New Topic/Question
Reply



MultiQuote



|