Exposing the exception handler

Aug 26, 2013 at 3:00 PM
I was digging around the source code, trying to work out how the ramifications of Exception handling and whatnot, and I realized that the code in Extensions.cs, where those extension methods are defined, is not thread safe. No worries, I think, I'll just define my own.

Oops, but I can't, because it's defined as internal. Can this property be made public in future releases? Or am I missing some architectural reason for making it internal?
Coordinator
Aug 27, 2013 at 8:29 PM
thanks for pointing this out. I will fix this this week.
Coordinator
Aug 28, 2013 at 1:50 PM
Could you confirm which class you are referring to. The Extensions.cs class is public.
Aug 28, 2013 at 4:19 PM
I'm referring to the ExceptionHandler property of Workflow<T>
Coordinator
Aug 29, 2013 at 1:15 PM
I can't see how this isn't thread safe. It is only being set once and should never change. I can't see how it can accessed inconsistsently.

Can to explain how this isn't thread safe.

Thanks.
Aug 29, 2013 at 2:17 PM
The ExceptionHandler property of Workflow<T> is safe enough, but I was wanting to define my own.

What isn't threadsafe is the Configure() and When() methods in Extensions.cs. What happens if I am defining a workflow on two different threads? The value of the static _workFlow in Extensions gets set in Confgure(). If I call this method on two different threads at the same time, _workFlow will be overwritten by one of the threads. Then, when When() gets called, _workFlow may have the wrong value depending on the calling thread.
Coordinator
Aug 29, 2013 at 2:43 PM
Ah. Thanks. I thought that might be the problem. I can't see how to make that thread safe.

These extension methods were a convenient wrapper around http://www.nuget.org/packages/exceptional/.

I am investigating whether the code behind this is thread safe and then will resolve the problems in the extension methods.

Meanwhile, you could just use conventional exception handling.

Thanks for pointing this out.
Aug 29, 2013 at 4:34 PM
Yeah, I don't see how you'd do it either, short of storing the state inside the workflow itself somehow.