Okay thanks David, it just makes testing failure scenarios a bit of a pain using simple methods, you have to set break-on-error to false, require-new-transaction to true and then you also have to clear the responseMessage and errorMessageList after the service call. But if that the way it's supposed to be then so be it.

Thanks
Scott

On 13/12/2009, at 3:45 PM, David E Jones wrote:


Yes, that's correct, it does not undo the error, it simply keeps it from interrupting the flow so you can do other things.

If you want to "undo" the error, or have it be independent, then technically it needs to run in its own transaction in addition to doing something to no pass the error up the stack.

-David


On Dec 11, 2009, at 1:23 AM, Scott Gray wrote:

I'm trying to use call-service's break-on-error="false" attribute but my simple method still returns an error at the end of the method, so break-on-error="false" seems to just delay the error instead of breaking straight away on the service call. This happens because the service call errors end up in the method context which is checked to determine the success of the simple method. I'm doubting this is the desired behavior because unless your simple method isn't wrapped in a transaction everything is going to get rolled back anyway regardless of the break-on-error setting.

Can anyone confirm or deny?

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to