catching errors from linked processes: simplest way?

Chris Pressey cpressey@REDACTED
Wed Apr 23 22:12:05 CEST 2003

On Tue, 22 Apr 2003 18:23:39 -0400
Vance Shipley <vances@REDACTED> wrote:

> It seems to me that since the problem you are trying to solve is an
> error handling one it should be solved in the error handler.  If the
> error handler needs to have knowledge of the structure of the code
> to do the error handling the way you want then so be it.

I ended up using a combination of this (for generic errors, where no
real awareness of the structure of the code is needed) and Ulf's
suggestion for 'assert' (for specific errors.)  'assert' is simple and
clear, and it's not error handling so much as simply error-causing, so
it's quite OK to put in mainline code as far as I can see.

My program looks nice now, and behaves nicely too.

Thanks to everyone who helped me understand!

I'm still fuzzy on a few things.  Hard to put into words, my head is
still swimming:

When you start an application (or, actually, any function that hides
several processes,) aren't what you really doing, is starting that
application's supervisor?

That is, if any process in the application exits with an error, the
supervisor notices, shuts down all its processes, and returns the error
to you (the caller of the application)?  So that, from your perspective,
the application just looks like a regular function call, which you can
catch to handle any of the errors in any of the processes inside it?

(I'm thinking specifically of applications that have a finite time
domain and a measurable outcome here, not a long-lived application with
no definate end.)

I realize I might not be explaining it well, but it's something that
always confused me from trying to grasp the concept from the OTP docs.

Thanks again,

More information about the erlang-questions mailing list