[erlang-questions] Exceptions and gen_server

Robert Virding <>
Sun Nov 8 19:47:29 CET 2009


There have been a number of different suggestions as to how you could
program this. I think the main thing for you to decide is *HOW* you want to
see the error, then it is relatively easy for you to program it. For
example:

- First off: do you want the error to crash the server or not? If so is
links and exit signals a good enough way for you to see the error?

- If the server is to live, how should your app see the error? Two valid
suggestions which have been given here are:

1. Signal the error using exit/2. This "simulates" the exit signals as if
the server had crashed.
2. Return an error value which either: returns an error value to the caller;
or generates an error using erlang:error/1. Which is best for you depends on
your app.

All these solutions are easy to program so the main problem is for you to
decide which is best for your app.

One thing I would *NOT* do is use throw/1 to signal error! Throw is for
non-local returns not errors. Using it for errors will just lead to
confusion and maybe errors if other parts of app assume it is a non-local
return. As try can differentiate between throw, exit and error it is
important that they are used for the right thing.

Robert

P.S. I would LOVE to change catch now so it only catches throws, but I don't
think it would be possible. :-(

2009/11/6 Anton Krasovsky <>

> What would be the standard way of returning/throwing an exception in a
> result to a gen_server:call?
>
> Would something like that be reasonable:
>
> a() ->
> case gen_server:call(..., a) of
>    {ok, Value} -> Value;
>    {error, Error} -> throw({error, Error})
> end
>
> and
>
> handle_call(a, ...) ->
> case ... of
>    {ok, Value} -> {reply, {ok, Value} , State};
>    {error, Error} -> {reply, {error, Error} , State}
> end
>
> Regards,
> Anton
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>


More information about the erlang-questions mailing list