catching errors from linked processes: simplest way?

Chris Pressey cpressey@REDACTED
Tue Apr 22 07:49:17 CEST 2003

OK, so, I'm actually trying to write 'aggressively simple' code now,
without open cases or inline error handling, and I've come across a case
that I can't see a simple way to handle.  (I can see a couple of
somewhat complicated ways to handle it, but wouldn't that defeat the
purpose :)

When I run the attached program I get the following output:

1> test3:start().
all OK
got "11"
got "21"
got "31"
got "51"
got "61"
got "81"
got "91"
got "181"

Pretty much exactly what I expected.  So far, so good.

If I change line 7 to
  case catch client(Pid, [10, 20, 30, 50, 60, atom, 90, 180]) of
Then when I run it I get

1> test3:start().
not OK: {'EXIT',{badarith,[{test3,client,2},
got "11"
got "21"
got "31"
got "51"
got "61"

Also what I expected.

But if I now change line 17 to
  Pid ! Head,
I get

1> test3:start().
all OK
got "10"
got "20"
got "30"
got "50"
got "60"
=ERROR REPORT==== 22-Apr-2003::00:25:16 ===
Error in process <0.30.0> with exit value:
** exited: {badarg,[{erlang,integer_to_list,[atom]},{test3,loop,0}]} **

Not exactly what I'd prefer to happen!

I guess what I'm thinking is, wouldn't it be great if 'catch' could
catch errors from linked processes.  I guess I'm also thinking that
someone's probably thought of this before, so there's probably a simple
way to do it, of which I'm unaware.

The complicated ways to do it that I can think of are:
- make the client process trap exits and use a receive loop in the
client to get them and re-throw them in the client process;
- monitor the server from the client process and use a receive loop in
the client to throw errors in the client process when the server bombs;
- catch errors in the sever and explicitly pass an {error, Reason} value
back from the server (exactly what I'm now trying to avoid)

All of these would require me putting a 'receive' in the client, which
is less than elegantly simple - it goes against the grain of what I'm
now trying to do, i.e. eliminate explicit, inline error-handling code
from the main logic.  If I have to resort to it, I will, but if it turns
out I don't have to, that'd be great.

Any suggestions would be appreciated.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test3.erl
URL: <>

More information about the erlang-questions mailing list