Hi, I'm not sure this will help you out, but in what comes to the system i'm currently developing (using drools expert), i've got this method "runRuleEngine" that collects facts and fire rules on them and i am able to catch any sort of error within the drools execution by surrounding that with try {} catch (Exception e) {}. The important part is that it took me a while to figure that out cuz eclipse didn't force me handle that, as if the called method didn't have "throws" (it usually shows a compilation error otherwise, right?). Just a thought. _ miguel On Wed, Mar 31, 2010 at 9:44 PM, nanic23 <nanic23(a)hotmail.com&gt; wrote: -- "To understand what is recursion you must first understand recursion"

+1 Documentation on this is unclear. Unit tests in drools-src handle exceptions using Fault nodes, but not real exceptions that are thrown by WorkItemHandlers. 1. Can I have Process or Composite node exception handlers catch my own (or any other) exception other than just "Faults"? and if so, how can accomplish that? How I register my custom exception handler? 2. If the above is possible... How can I pass the exception to the custom exception handler so I can work with it (log the stack trace, etc)? /Anatoly -- View this message in context: http://n3.nabble.com/How-to-do-Exception-Handling-tp689387p693018.html Sent from the Drools - User mailing list archive at Nabble.com.

The way I see it, you can attach an arbitrary number of "fault handlers" to a given running process. All that is needed is for the process to have one or more fault nodes having fault names which are handled by the fault handlers of the process. It in in these fault handlers that I raise custom/application-specific exceptions. I've personally found this fault/fault handler concept to be pretty flexible in terms that the process failure/exception logic resides at a single location viz. the fault handler of the process. This is more-so conversant with the workflow terminology i.e. there are no exceptions, just logical faults which are not checked/unchecked and have no logical meaning of a stack-trace. Just my 2 cents. Peace, /T\ -- View this message in context: http://n3.nabble.com/How-to-do-Exception-Handling-tp689387p701157.html Sent from the Drools - User mailing list archive at Nabble.com.

Miguel, I think your work item handler should not be throwing an exception, just because a java exception is low-level and linked to one specific implementation and we try to keep the processes a little higher-level. So what could you do then to model exceptional situations when executing a work item? I suggest you use a try-catch block to catch the java exception and translate that into something higher-level, like: - your work item can contain result parameters, in case of some failure you could fill in a special result parameter with some data, the process instance can then map this result data to some process variable which will allow you to use this data, for example in a XOR split node immediate after this work item node to check for exceptional situations, or in an on-exit action linked to the workItemNode (which could then for example also throw a fault so that the nested exception handler mechanism kicks in) - your work item handler could decide to send a signal to the process instance to signal the occurrence of some exceptional event, and you could use an event handler to listen to that event Depending on your exact use case, I can probably think of a few more alternatives (like using abortWorkItem instead of completeWorkItem), but they might not be all ready to use out-of-the-box. Kris ----- Original Message ----- From: miguel machado To: Rules Users List Sent: Thursday, April 01, 2010 1:57 PM Subject: Re: [rules-users] How to do Exception Handling??? Hi, I'm not sure this will help you out, but in what comes to the system i'm currently developing (using drools expert), i've got this method "runRuleEngine" that collects facts and fire rules on them and i am able to catch any sort of error within the drools execution by surrounding that with try {} catch (Exception e) {}. The important part is that it took me a while to figure that out cuz eclipse didn't force me handle that, as if the called method didn't have "throws" (it usually shows a compilation error otherwise, right?). Just a thought. _ miguel On Wed, Mar 31, 2010 at 9:44 PM, nanic23 <nanic23(a)hotmail.com&gt; wrote: I have a ruleflow that handles exceptions when they are raised by a "Fault" node but I am not being able to accomplish the same if an exception is thrown by a workItem or an action node instead. I have a workItem node with a work item handler that throws a RuntimeException. My exception handler in the composite node is not catching this exception. So, question 1) how can I handle runtime exceptions thrown by my workItemHandlers? 2) how can I get a hold of the exception to log the stack trace? Any ideas or tips are very appreciated. Nick. -- View this message in context: http://n3.nabble.com/How-to-do-Exception-Handling-tp689387p689387.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- "To understand what is recursion you must first understand recursion" ------------------------------------------------------------------------------ _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

@Anatoly, I think that JVM crash, Hard Drive crash, or Network failure are not responsibility of the framework. In this kind of situations you must create the mechanisms to handle each situation. The only framework concern is that the information persisted is always coherent. @Kris The 3.8 Exceptions in the docs is well focused in the high level process faults. On Fri, Apr 9, 2010 at 1:26 AM, tolitius <webakaunt(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

Ed, feel free to contribute with documentation about how you implement your own mechanisms to handle exceptions. I will try to create a blog post about that too. On Fri, Apr 9, 2010 at 11:52 AM, Ed Staub <estaub(a)telcordia.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

The main problems I see when translating a java exception to a process exception automatically: - the exceptions are too low level, no business user understands NumberFormatException or ClassCastException, and the error could come from deep inside the invoked service - by making it automatic, the user is not forced to think about it and thus might forget about it, so you might end up with aborted process instances (default behaviour if no exception handler can be found) and the user won't even notice - the handler is actually the link between the process engine and the environment, I see it as a contract between the two, and what data is exchanged (input/output) is defined It is trivial to simply create an AbstractWorkItemHandler that would transform a Java exception to a process fault with the same name. If you want this as the default behaviour, I suggest you do that. But if we build this into the framework, it will be more difficult to change it if you don't want this behaviour (and we try to keep the maximum flexibility possible). Kris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

I'm not convinced that converting a java exception to a process fault with the same name is a solid behaviour. In java it is perfectly permissible and valid for a piece of code to change the exception it throws to a subclass of that exception (eg throw a FileNotFoundException instead of a generic IOException). Any legacy code which catches the IOException will keep working perfectly (unless they are do something really stupid). However drools would be doing something stupid, it would be matching based upon the exception name not type hierarchy and the flow would suddenly break when you no longer have the right fault handler matching the right exception name. I'd suggest the more sensible and solid default action would be to create of a fault with a name UnhandledException (and the exception as a payload). This could be extended later so that a map from exception type -> fault name could be produced using the same matching logic as catch blocks. Thomas ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com

@Kris Thanks for the input. While I keep investigating on my side I thought of asking you this quick question given that you said this might be trivial to do.... I am implementing an AbstractWorkItemHandler that catches exceptions and the intention is to map these to Faults with the same name. (just as you mentioned) I then would like to raise a Fault from my AbstractWorkItemHandler and handle these faults with Process Exception Handlers that might signal an event for further processing of the Fault. Now the question is: Can I raise a Fault programmatically in my AbstractWorkItemHandler (i.e. without having any Fault Nodes in my workflow definition) ? If yes, how can I do this? Please let me know if you have any question. Thanks, Nick. -- View this message in context: http://n3.nabble.com/How-to-do-Exception-Handling-tp689387p718847.html Sent from the Drools - User mailing list archive at Nabble.com.