I think that the mixture of dynamic class creation and compilation for RHS (nested and recursive code for pattern matching) and nested node execution inside business processes complicate the exception propagation drastically. Also it's important to note that the knowledge layer was added on top of the rule engine in order to do an abstraction.
But you are right, sometimes it gets really complicated to find out what it's happening.
I am just curious to learn a little more about Drools evolution history to
understand why would Drools eat so many Exceptions the root cause of which
is impossible to even guess, without stepping into the Drools source code...
That happens in many Drools components, so my curiosity just wanted to be
fed on how this "pattern" came to be.
Any old school Droolers can contemplate?
/Anatoly
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Pattern-to-Eat-Real-Exceptions-tp1075763p1075763.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users