Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

handling exceptions

Avatar

Level 6
Hi,



I would like to ear from you about best practices to handle exceptions in workbench processes.



As far as I understand, one can handle exceptions only in some services. Also, each kind of exception must be handled, one by one (ex.: one route from the service that throws the exception by each exception).



This procedure as a lot of limitations: first, the services that expose/throws exceptions only throws some kind of exceptions. So, it is possible to make a route from all the exposed exceptions, but then get an unhandled error. Second, the process become too messy. Third, it seems we can´t garantee a fixed response message (in case of error), because we can´t control all the exceptions.



So, my question is: Am I right? Is it really true that we can´t catch all kind of process exception, for at least control the message we sent to the calling application?



If this is not possible, I really dont´understand how one can use this kind of processes in a production environment... So, I hope Im wrong :)



thank you
10 Replies

Avatar

Level 10
"This procedure as a lot of limitations: first, the services that expose/throws exceptions only throws some kind of exceptions. So, it is possible to make a route from all the exposed exceptions, but then get an unhandled error. "



You should have a generic SYSTEM EXCEPTION that should catch the ones that are not specifically exposed.



"Second, the process become too messy. "



Agreed.



"So, my question is: Am I right?"

Partially :)



"Is it really true that we can´t catch all kind of process exception, for at least control the message we sent to the calling application?"



Have you tried the SYSTEM EXCEPTION?

Also we have the Exception event that should catche all exceptions that occurs in the system. You also get an Exception object that gives you the error code, description and message. That might be more useful for you.



Jasmin

Avatar

Level 6
Jasmin,



You said: "You should have a generic SYSTEM EXCEPTION that should catch the ones that are not specifically exposed." Should system exception get all the exceptions, even those specifically exposed? Im almost sure that some exceptions not exposed are not got by system exception.



Where can I read about that Exception event?



Thank you

Avatar

Level 10
"Should system exception get all the exceptions, even those specifically exposed? "



No. System Exception will give you all exceptions that are not specified in the list.



"Im almost sure that some exceptions not exposed are not got by system exception. "

It's possible. If it doesn't through an exception you could log a bug.



"Where can I read about that Exception event? "

Check the Workbench help.



Jasmin

Avatar

Level 9
Hi Neptuno

As far as I know, Jasmin is completely correct.

The only way that you won't get the exception is if the write of the component "eats" the exception - i.e. catches it, and doesn't rethrow it or another exception.

Howard

http://www.avoka.com

Avatar

Level 6
Hi,



I read the help in workbench about the exception event, but I still was not able to figured out how it works. Is there any other help about this topic?



Thank you

Avatar

Level 10
Just drop the Exception event in a new process as a start point.



Create a string variable of type input and associate it to one of the Exception property in the CallBack tab.



Record your process and see if it's being called when an exception occurs.



Jasmin

Avatar

Level 6
Jasmin,



I couldnt make it work in any way. I sont even understand the theory behind this approch: how can an error thrown by any activity on my process be catch by this strat event... maybe we are talking about different things.



Unfortunatly, Im not able to catch even "simple" exceptions like these:



In a setValue service, mapping to variable that doesnt exist (or that it was deleted) doesnt throws any exception; This is difficukt to maintain if the process is big.



In a setValue service, if I use a deserialize function in a variable that doesnt exists (or with an invalid xml), I will get an error, but I will not be able to handle it;



In a web service component change something like the target url or operation throws an error impossible to catch even if we draw all the events exception associated to this object;



These are just examples.



thank you

Avatar

Level 6
Jasmin,



I couldnt make it work in any way. I sont even understand the theory behind this approch: how can an error thrown by any activity on my process be catch by this strat event... maybe we are talking about different things.



Unfortunatly, Im not able to catch even "simple" exceptions like these:



In a setValue service, mapping to variable that doesnt exist (or that it was deleted) doesnt throws any exception; This is difficukt to maintain if the process is big.



In a setValue service, if I use a deserialize function in a variable that doesnt exists (or with an invalid xml), I will get an error, but I will not be able to handle it;



In a web service component change something like the target url or operation throws an error impossible to catch even if we draw all the events exception associated to this object;



These are just a few examples.



thank you

Avatar

Level 9

Hi Neptas

The SetValue component does not throw any exceptions, as you indicate.

If an exception does occur, the process will stall - you will be notified of this via email, you can see the stalled process in the Adminui, fix the process, and then retry the stalled action.

I agree in general that:

  • It would be nice if we could handle exceptions in more streamlined ways
  • All components threw exceptions. (I'd log a feature request with support and get this logged.)

However, the types of exceptions you describe are errors in the process, that simply need to be fixed before going into production.

Handling exceptions at runtime due to variations in process data, etc, are better handled by exception routes.

I hope that a) I understood and b) this helps.

Howard

http://www.avoka.com