qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aconway <acon...@redhat.com>
Subject Default error behavior in event-driven APIs (was Re: Error detection/handling)
Date Mon, 05 Oct 2015 14:58:46 GMT
On Wed, 2015-09-16 at 14:04 +0200, Tomáš Šoltys wrote:
> Hi,
> 
> I have a client that sends a messages to broker. It can happen that
> message
> contains incorrect subject which will trigger ACL deny on the broker.
> But on the client side everything seems to be OK.
> 
> How do I detect such errors?
> 
> Regards,
> Tomas

A different but related question: what should be the default error
handling behavior in an event-driven API?

The "silently ignore" option is just bad IMO. Telling people after
their applicaiton has malfunctioned but continued to run with bad data
that "hey didn't you have an on_*_error handler" is not friendly.

Composable event-driven APIs pose a challenge here. It's not really ok
to require at compile time that event handlers *must* have on_*_error
handlers, since it would be legit design to have one handler that
deliberately doesn't handle errors but is intended to be used with
another that does.

At runtime, when an error occurs it is possible to throw, raise, panic
or abort if no user handler takes care of it. I would argue that this
is better than silently ignoring it, on the "fail fast" principle. The
user *should* have error handlers, if not their program is incorrect
and it is better to crash than close your eyes and carry on down the
wrong path.

It would be much better to analyze the user's handlers and detect the
"no error handler" problem at the start of the event loop, but in
general that is tricky.

I would advocate that all bindings should throw/raise/panic/abort on an
unhandled error as a last line of defence, and we should add
better/earlier safeguards if we can come up with them

Cheers,
Alan.

Mime
View raw message