How to catch Exception Message in Erlang?

Question

This is the Exception message thrown by Gen_server when its not started.

([email protected])32> R11 = system_warning:self_test("SysWarn").
** exception exit: {noproc,
                    {gen_server,call,
                     [system_warning_sup,
                      {start_child,
                       {system_warning_SysWarn,
                        {system_warning,start_link,[{system_warning_SysWarn}]},
                        permanent,10,worker,
                        [system_warning]}},
                      infinity]}}
     in function  gen_server:call/3
     in call from system_warning_sup:'-start_child/1-lc$^0/1-0-'/1
     in call from system_warning:self_test/1
([email protected])33> R11.
* 1: variable 'R11' is unbound

Now, What I want to do is to catch this exception message & put into variable R11 (showed above as unbound). I want to do so because if gen_sever is not started then I want to start after getting this message. I also tried using handle_info but not able to trap the exception or may be not able to implement it correctly. Can any body please help me with this problem providing some code for example.

Answer 1

Both the answers from @W55tKQbuRu28Q4xv and @Zed are correct but a little terse. :-)

There are two ways to locally catch an error: catchand try. Both will also catch non-local returns generated by throw.

catch is the older and simpler of the two and has the syntax catch Expr. If an error occurs in the expression being evaluated then catch returns {'EXIT',ErrorValue}, otherwise it just returns the value of the expression. One problem with it is that there is no way to see how the error return value has been generated so it can easily be faked in the expression. In the same way you can't see if the return value comes from a throw. N.B. this is not a bug but a feature. Also it is a prefix operator with a low priority so you would normally use it like:

R11 = (catch system_warning:self_test (....))

to avoid confusion. This was a mistake, it should have been catch ... end.

throw is more complex and allows you much greater control over over what to catch and how to handle both the normal returns and error/non-local returns. See the manual for a full description. @Zed's example shows the simplest case which catches everything.