What are you trying to do?

-David


On Dec 13, 2009, at 12:32 AM, Scott Gray wrote:

> 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
>>> 
>> 
> 

Reply via email to