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 <
[hidden email]> 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?
>>
>>
>
Locked
