<< Verdere info omtrent telenet digicorder etc.. | New version of DasBlog with extra and jforsythe macros installed >>

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

Tags: .net, codeproject, safe method invoker

Development

w00t : Building a new app from the ground up : methodology, technology & tools used This is one of the articles in our series; the parts are: Methodology, technology & tool...Opengl / c# source - Paul Bourke 3d Supershapes(Programmers only !!! ) While checking out some stuff on my PC I noticed some old sloppy code lying...Override interface mappings and creata a generic entity version filterIntroduction For one of my customers I needed to have some kind of versioning for a whole bunch of ...

Comments

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

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 #

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 |