Alternatives to exceptions for error handling

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Dec 1 05:54:50 UTC 2020


On Mon, Nov 30, 2020 at 06:48:05PM +0000, Roman Kashitsyn via Digitalmars-d wrote:
> On Monday, 30 November 2020 at 09:58:36 UTC, Gregor Mückl wrote:
> 
> > What kind of error conditions are you talking about that you
> > consider handleable locally? Do you have concrete examples? I am
> > asking because this is way outside the experiences I have made
> > regarding error handling and I would like to understand your
> > perspective.
> 
> 
> Sure, let me give a couple of examples.
> 
> Imagine you are writing a step of a pipeline that needs to support
> backpressure.
> When you push data downstream and the call fails because downstream is
> overloaded, a good recovery would be to start buffering data and
> propagate the failure upstream when the local buffer fills up.
> If we terminate the whole pipeline each time we have a minor
> congestion, we'll never have anything done.

Why would it terminate the whole pipeline each time there's a
congestion?  Catch the exception at the right point and run fallback
code, or whatever it is, then continue.  That's the whole reason 'catch'
exists.

Of course, aborting because of Errors is a different story. That's to do
with logic problems in the code, in which case terminating may be the
only way to recover properly.  To prevent terminating the whole pipeline
in that case, I'd think about partitioning the application into a master
thread/process and a number of workers, and the workers may abort upon
error but the master simply reschedules the work to another worker.


> Another example: I was once implementing a distributed task execution
> service using Zookeeper.  It had scheduler processes and worker
> processes distributed across multiple DCs. Only one scheduler must be
> active at any time, and other scheduler instances wait in stand-by
> mode in case the leader
> dies or becomes partitioned.
> First, Zookeeper API is callback-based, and throwing exceptions into
> the event-loop not controlled by your application makes little sense.
> So we already need a different error handling mechanism for such
> cases.
[...]

So wrap the entry point into the user code with a try/catch block, and
the catch block will propagate the error using whatever suitable channel
of error communication is (e.g., write a message to a error-handling
socket, or send a message to a controller then quit, etc.).  If you
like, you can even mark it nothrow to ensure any user code will always
catch the exception instead of letting it propagate into the event loop.

Just because you use exceptions, doesn't mean it has to be used
throughout the entire call stack indiscriminately.


T

-- 
It's bad luck to be superstitious. -- YHL


More information about the Digitalmars-d mailing list