Mar 9, 2013 at 6:01 AM
Edited Mar 9, 2013 at 6:02 AM
That's an interesting idea. Feel free to add a suggestion at
My first thought is that the catching of an exception is currently very central to the functioning of the block. The throw of the exception is what triggers the start of the (potential) retry process. So if we aren't using exceptions then how do we know when
to test for retry conditions? If the exception is still what triggers the process then how do we know where to get the information (i.e. the <T>) to pass to ITransientErrorDetection?
Now, I'm not saying these are insurmountable issues (I just started thinking about it!) just that it may complicate the design beyond the mandate of the block. Mind you, that's just my initial 2 cents and not canon. It's always possible (likely? :) ) that I
don't have the big picture or am overlooking some easy changes.
Also, if you think you need that type of functionality then feel free to modify the source code to suit your needs.
Enterprise Library support engineer