quit method execution on event

[Peter Duniho]

I believe that you are wrong. Unless you have written a multithreaded
program, no event can occur until all previously executing code has
finished and execution has returned into the piece of code that fires
the event, so no method can be interrupted by the event.

Unless, of course, the event is raised by some method called by the
method that's executing.

It's possible that this is what the OP is running into, giving him a
false impression of how events work.

This can only happen if your code is multithreaded. In this case you
will have written code somewhere to start the separate thread where code
is executing at the same time that an event happens. If you want to stop
the separate thread from your event code, you can execute a
thread.Interrupt or thread.Abort on the thread that you previously started.

Noting, of course, that aborting a thread is generally a very poor way
to manage thread execution. Thread.Interrupt is somewhat better, but
only if you've specifically designed the thread to handle the generated
exception correctly. It's not something I'd want to just stick into an
existing thread without fixing the design to take it into account.

That said, I agree that _something_ along those lines is going to be
needed to implement the behavior asked for. But generally, there would
be a more explicit inter-thread communication (like a volatile flag
telling the thread to exit, which it can check periodically), IMHO.

Pete

 

[Guest]

Usually when a method is executing and an event occurs the event handler
executes then the thread is returned to the original method.

I have a case where I want my event handler to cancel execution of any
existing methods in process. Is there a way?

 

[Alberto Poblacion]

Usually when a method is executing and an event occurs the event handler
executes then the thread is returned to the original method.

I believe that you are wrong. Unless you have written a multithreaded
program, no event can occur until all previously executing code has finished
and execution has returned into the piece of code that fires the event, so
no method can be interrupted by the event.

I have a case where I want my event handler to cancel execution of any
existing methods in process. Is there a way?

This can only happen if your code is multithreaded. In this case you will
have written code somewhere to start the separate thread where code is
executing at the same time that an event happens. If you want to stop the
separate thread from your event code, you can execute a thread.Interrupt or
thread.Abort on the thread that you previously started.

 

[Guest]

Ok, the parent method is any one of several procedures each of which access a
function (in another class) with a try-catch block. The catch block triggers
an event which is handled in the main class with an error procedure. When the
error procedure completes the parent method resumes.

I could set a Boolean "IsErrror" variable to true and include a conditional
in each of the many possible parent methods and abort the method if
ISError==true, but that is inelegant. I was hoping there was some way to
abort the sender method from the error event handler.

 

[Peter Duniho]

Ok, the parent method is any one of several procedures each of which access a
function (in another class) with a try-catch block. The catch block triggers
an event which is handled in the main class with an error procedure. When the
error procedure completes the parent method resumes. [...]

So you've got an event that is raised as part of your error handling?

Why not just rethrow the exception after you've done your own local
error handling?

Pete

 

[Guest]

Ok, the parent method is any one of several procedures each of which access a
function (in another class) with a try-catch block. The catch block triggers
an event which is handled in the main class with an error procedure. When the
error procedure completes the parent method resumes. [...]

So you've got an event that is raised as part of your error handling?

Why not just rethrow the exception after you've done your own local
error handling?

Pete

Pete;

Sorry I'm so dunderheaded.

If I use this approach will I then need to have a try catch block in each of
the parent procedures?

 

[Peter Duniho]

[...]
If I use this approach will I then need to have a try catch block in each of
the parent procedures?

That depends on what your intent for the code's behavior is. You
haven't been very specific about what it is exactly you're trying to do,
so it's very difficult to offer any specific advice.

Your previous post seems to imply that you do not want the "parent"
method to continue executing, so based on that I'd say no, you would not
want to catch the exception in the "parent" method.

Now, whether you want an exception handler in the code that calls the
"parent" method, I can't say. It really depends on what exactly it is
you are trying to accomplish. But generally speaking, if you want a
section of code to stop executing, execution still has to resume
_somewhere_, or else the thread that's currently executing has to itself
exit.

Without knowing exactly how you want your code flow to be adjusted
according to the error, I can't really say what the best way to do that is.

Pete