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.
