exception in class and passing of parameters

[Mike Pokraka]

Hi,

Mike's suspicions are entirely correct: The WF engine picks up that an
exception has occurred and doen't bother binding anything back.

My take on SAP's design is that an exception is an error condition, which 
invalidates return values. A 'business exception' should thus be modeled
with a return value that gets checked later.

Regarding return parameters in BOR, I've never liked them and almost
always gotten by without them in the BOR world. In some cases it's a minor
inconvenience compared to BOR of having to check a parameter in a separate
condition; but in other cases (if the step is simple and doesn't modify
any data) it actually simplifies things because you can even skip the step
completely and plug a functional method straight into a condition.

Cheers,
Mike

On Thu, May 20, 2010 10:32 am, Robert van den Berg wrote:
>
> Hi all,
> Â 
> I discovered where the evil is. In the old situation with BOR objects,
> the method has a return parameter (setting on the method). So the
> 'exceptions' are not exceptions but return values.
> Â 
> Is there a possibility to use this with a Class method?
> Â 
> Best regards,
> Robert
> On May 20, 2010 10:58 "Robert van den Berg" <wug at bergtop-ict.nl>wrote:
>> Mike,
>> Â 
>> it does not realy need a statement to pass the value, does it?
>> Â 
>> The export parameter is set by the normal ABAP statement:
>> APPEND ls_amr TO amr_reject.
>> AMR_REJECT is set as exporting parameter.
>> Â 
>> Regards,
>> Robert
>> On May 20, 2010 10:48 "Mike Gambier" <madgambler at hotmail.com>wrote:
>> > Jocelyn,
>> > Â 
>> > I'm not sure that's entirely accurate anymore. ABAP was adjusted
>> > some time ago to return EXPORTING, TABLES and CHANGING parameters in
>> > FMs or ABAP Class Methods even if you raise an exception.
>> > Â 
>> > We have several examples of where an Exception is thrown and we can
>> > still trust the value of an Exporting 'Error' flag or Application
>> > Log instance as well.
>> > Â 
>> > The flaw highlighted by Robert I think is buried in the way the
>> > value being received is being bound (or not) into the Method
>> > container.
>> > Â 
>> > Mike GT
>> > Â 
>> > From: jocelyn.dart at sap.com
>> > To: sap-wug at mit.edu
>> > Date: Thu, 20 May 2010 10:30:07 +0200
>> > Subject: RE: exception in class and passing of parameters
>> > Hi Robert,
>> > Â 
>> > If you raise an exception, the exporting parameters are NOT returned
>> > to the calling application (not just workflow – all calling
>> > applications)  – exact same behaviour as function modules.  The
>> test
>> > tool “cheats” a little.  
>> > Â 
>> > So for a synchronous task either use an additional exporting
>> > parameter to indicate success/failure or use an exception class to
>> > update the workflow log with your returned value.
>> > Or raise an event (with or without parameters) – and make your task
>> > asynchronous.
>> > Â 
>> > Regards,
>> > Jocelyn
>> > Â 
>> > From:sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
>> > Behalf OfRobert van den Berg
>> > Sent: Thursday, 20 May 2010 6:17 PM
>> > To: SAP Workflow Users' Group
>> > Subject: exception in class and passing of parameters
>> > Â 
>> > Hi Group,
>> > Â 
>> > I have a task which uses a method of a class. This method has export
>> > parameters and exceptions.
>> > Before the exception is raised, the export parameter is set.
>> > Â 
>> > The problem is that, when the exception is raised, the export
>> > parameter is empty. When I test the method from the class builder,
>> > the export parameter contains a value but when I test the workflow,
>> > the workflow container is empty.
>> > Â 
>> > Does anyone have an idea?
>> > Â 
>> > Regards,
>> > Robert
>> > Â 
>> > Get a free e-mail account with Hotmail. Sign-up now. <about:blank>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>