On Dec 4, 2006, at 8:05 AM, Chris Howe wrote:
Since the method being called is throwing an error and
it's not being caught, wouldn't the error get spit out
in the log before getting to the check-errors?
If that's happening and the exception is not making it back through
then it's a bug.
In general this is a service environment and not a "Java" environment
and so exceptions aren't all that helpful. Passing messages around is
the way to go, and we do have various things like a message wrapper
object so you can identify where the error happened, and the message
Map that Jacopo mentioned so you can give each message a name/key.
What I'm wondering about your proposal is how it is different and
better than existing methods of error handling and message passing,
including the two I mentioned above.
-David
--- Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
Hi Chris,
just my 2 cents: wouldn't be better/cleaner to just
populate the errors
map (not sure about the details here) so that the
errors can be checked
using the <check-errors/> operation?
Something like this:
<call-object-method ...>
...
</call-object-method>
<check-errors/>
Jacopo
Chris Howe wrote:
I'm interested in adding support for exception
handling for the call-object-method and
call-class-method operations in minilang. Let me
know
if this approach sounds feasible.
and a child node of <exception/> to call-*-method.
create an ExceptionObject class that will parse
the
element
in the parameterIter while clause in
CallObjectMethod.callObjectMethod and
CallClassMethod.callClassMethod have it evaluate
for
"exception" while it's evaluating for "field" and
"string" and add it to an additional list for
exceptions to be added to
CallObjectMethod.callMethod
create an exception iterator and loop through each
Does this sound doable before I try to do it?
