Safe method invoker in c#

by Tom 27. June 2007 01:04

Today I was reading an article on codeproject by Mark Clifton about using a safe invoker for a method.

While the idea was quite good, I think the implementation was a bit bloated, so I posted a comment with my own implementation.

This was the implementation I posted:

class SafeMethodInvoker

{ public delegate void ExcDlgt(Exception e);public delegate void voidDlgt();

public delegate bool boolDlgt();

public static void Run(boolDlgt del, int TimeOutMs,

ExcDlgt Critical,voidDlgt Failure,voidDlgt Timeout )

{

Thread t = new Thread(delegate() { try { if (!del()) Failure(); } catch (Exception e) { Critical(e); } } );

t.Start();

if (!t.Join(TimeOutMs)) Timeout();

}

}

}

Way shorter as you might see

Bookmark and Share

Tags: , ,

Development

Comments

6/27/2007 6:36:46 AM #

Marc Clifton

While your code is definitely more elegant in its core functionality, it is not a replacement, for the following reasons:

* lost the timeout on the thread start (though the Join handles this but it doesn't distinguish between the thread not actually running vs. a call timeout)
* failure and exception calls run in the worker thread
* not killing the worker thread when the call times out
* no tests for handling cases where the error handler methods are null
* lost the retry function
* lost the ability to ignore timeouts when debugging
* lacks the debug statements I had in the original code
* lost the thread start check that I actually found important under certain situations

When you put all that back in, the only thing of interest that your code leverages to reduce the size is the Thread.Join call.  That is more elegant and is easier to clean up from a failure.  

Marc

Marc Clifton |

6/27/2007 8:10:15 AM #

Tom

Marc Clifton wrote:On closer inspection, while your code is definitely more elegant in its core functionality, it is not a replacement, for the following reasons:

You are absolutely right here. I shouldn't have stated the code as a replacement, more of a quick and dirty way of doing this...

* lost the timeout on the thread start (though the Join handles this but it doesn't distinguish between the thread not actually running vs. a call timeout)

I suppose I would need to wrap the thread.start & join within a try/catch block, and pass the exception to the Critical method ?

* failure and exception calls run in the worker thread

Actually I think this would not be a problem?

Marc Clifton wrote:
* not killing the worker thread when the call times out
* no tests for handling cases where the error handler methods are null
* lost the retry function
* lost the ability to ignore timeouts when debugging
* lacks the debug statements I had in the original code


These can be easily solved, but as you state, the would extend the code quite a little bit, so it would probably not make such a big difference anymore...

Tom |

Comments are closed

About me

Tom Janssens op LinkedIn

Tom Janssens op twitter

Core bvba RSS

My name is Tom Janssens and I am the owner of Core bvba, a software and consultancy company.
I am married to Liesbeth and have 2 sons named Quinten and Matisse.
ICT is both my job and passion.
Next to this my other hobby is actively playing music (mostly guitar), and I am also a lousy poker player.

I am also the founder of the following LinkedIn groups:
BDD Professional
Asp.Net MVC professional

More info about me and my company...