Re: catching errors from linked processes: simplest way?

Hi, glad you found a solution you are satisfies with.

Regarding starting an application, or as you put is, the
top-most supervisor of that supervision tree:

The idea in OTP is that we make a difference depending on
in which context a "member process" terminates.

During their start-phases (before all processes come past
their init-phases (leaving the function named init)):
Then you in the sence of making the function call to the
start-function will get an error-return value (not an exit
or similar). Such errors are referred to as start-errors and
reported as such if you run SASL. No process is allowed to
terminate during the init-phase.

After the successful start-up:
Then your start function-call has already returned {ok,Pid}.
If you used start-link or otherwised linked yourself to that
supervisor, you will get the exit-signal 'shutdown', indicating
that the supervisor terminated nicely (i.e cleaning up properly).

Processes may also terminate for "natural" reasons. OTP differs
between illegal and legal terminations. The permanence of a
process determines whether it is legal or illegal (a permanent
process may never terminate for instance).

Then you can of ocurse also have the scenario where you set
the restart intensity of your supervisor(s), to allow restarts
before it/they give up and terminate them self/ev.

/Lennart



Chris Pressey wrote:
> On Tue, 22 Apr 2003 18:23:39 -0400
> Vance Shipley <vances@xxxxxxxxxxx> 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,
> -Chris


--
-------------------------------------------------------------
Lennart Ohman                   phone   : +46-8-587 623 27
Sjoland & Thyselius Telecom AB  cellular: +46-70-552 6735
Sehlstedtsgatan 6               fax     : +46-8-667 8230
SE-115 28 STOCKHOLM, SWEDEN     email   : lennart.ohman@xxxxx