Gaining access to an error code value from Script Task?

[mindcrime]

Hi all, quick question… in Activiti, after a Boundary Error Event has fired in response to a BPMNError thrown from Java code, is there a way to gain access to the value of the error code which the BEE fired on, in a script task following the BEE?  Is it stored as a process variable, or is there an API call to get it?

The reason I ask, I'd like to handle multiple potential "technical" errors by rethrowing as a BPMNError, then starting a User Task for the "IT Support" group, and then - after completion of the User Task - branch back to the appropriate point in the process based on which error code was fired earlier.

[jbarrez]

I'd like to handle multiple potential "technical" errors by rethrowing as a BPMNError,

Don't you need multiple boundary events then?

Technical exceptions should be handled differently, as the BpmnError is actually build for business errors.

[mindcrime]

I'd like to handle multiple potential "technical" errors by rethrowing as a BPMNError,

Don't you need multiple boundary events then?

I mean, from different service tasks.  For now, we're treating any "technical error" as equivalent to any other, but any service
task can potentially generate one.  So after the User Task completes (once somebody in support has fixed the problem, presumably) we want to branch back to the appropriate point in the workflow.

Technical exceptions should be handled differently, as the BpmnError is actually build for business errors.

LOL… yeah, that's exactly what the docs say, and the approach I *was* taking.  Then another Activiti Developer pointed out that
just turning the Java exceptions into BpmnError is the most straightforward way to use normal BPMN constructs for dealing with this
situation, and when I sat down and looked at it, it does seem to be the most straightforward path.   The BEE fires, we branch
to a User Task, and then go back.  Unless there's something I'm missing, this seems pretty clean and straight-forward.

[frederikherema1]

I was that other developer As the use case he described was actually a technical error that should be handled in the process, turning the technical error in a business-error.

You can use multiple catching-events (which have their ow error-code). Some service/scripttask/listener after each catching-event could store a variable in the process, which could be accessed by the service-task that has the logic in it to handle the error.