On Mon, 2017-04-03 at 11:32 +0200, Daniel Pocock wrote:
>
> On 30/03/17 19:03, Alan Conway wrote:
> >
> > My preferred coding style would be to never throw exceptions out of
> > a
> > handler unless you want to stop the process. You could catch the
> > exception out of run() and recover/restart but at that point you
> > have
> > lost most of the context for the problem so IMO it would be
> > difficult
> > and error-prone. I wouldn't do it.
> >
>
> I agree it is best to do this in the handlers.
>
> Many of the examples don't override most of the handlers. In some
> cases
> the default handlers throw exceptions that propagate to the code that
> invoked run()
>
> Is it possible to specify exactly which of the handler methods must
> be
> overridden to ensure all foreseeable error conditions are handled
> within
> an application?
>
Excellent point. At the very least that should be clearly documented.
Since you can't compile the docs, you can write a boilerplate base
handler that implements every on_foo() function as:
on_foo(...) {
try { proton::messaging_handler::foo(...) }
catch(std::exception& e) { default_error_handling(e); }
}
Annoying, but a once-off task. You can probably template it in C++>=11,
if you dare.
astitcher: we could extend the C++ API to expose a per-thread run loop
like the C proactor. Max flexibility and avoids the boilerplate, but
exposes more mechanics and provides more options for user to shoot self
in foot. Just a thought.
> In this case the client is actually a daemon (the reSIProcate
> registration-agent[1] and the AMQP queue is being used to send
> commands
> to it. Eventually we would also like to have the SIP proxy accepting
> commands through a queue, it already has support for commands
> submitted
> through a socket (repro.config / CommandBindAddress[2]). While these
> processes are clients in the AMQP model, they are meant to be long
> running and stateful processes and so I need to have a comprehensive
> approach to ensure they don't get brought down by an exception.
+1, when I said "client" I was thinking of a short-lived process that
can just bail on error - anything else needs the kind of exception
handling you describe.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
