Desgrange.net

Exception

In a programming language, an exception is something that could be generated when the system is behaving outside the normal execution path. An exception is mostly an error. In lots of programming languages, developers use exceptions as a meaningful information to do something or not.

For example, while reading a file, an exception can be generated because the file does not exists. The developer may choose to catch the exception and display a popup to ask the user to choose an other file, or the developer may not catch the exception because the file must have been there and if it's not there it's because something wrong is happening but the developer has no clue about what to do, so the best solution is to let the system crash (as opposed to try to do something and maybe enter in an inconsistent state).

Exceptions in Erlang

In Erlang there are exceptions too.

-module(exceptions).
-compile([export_all]).

run() ->
    io:fwrite("Test exception 1 starting...~n"),
    exception1(),
    io:fwrite("Test exception 1 finished.~n"),
    ok.

exception1() ->
  erlang:foo().

Running the function run will run exception1 which throws an exception (the function foo does not exist in module erlang) and is not catched by run (so the second fwrite is not displayed):

$ erl -s exceptions run
Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false]

Test exception 1 starting...
{"init terminating in do_boot",{undef,[{erlang,foo,[]},{exceptions,run,0},{init,start_it,1},{init,start_em,1}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()

Types of exceptions

In Erlang there are 3 kinds of exceptions that can be generated:

• normal exceptions, user generated (throw(Reason))
• errors, something is going really wrong, should not be catched (erlang:error(Reason))
• exit, used to terminate current process (exit(Reason))

Catching an exception

• Catching an exception with catch:

run() ->
    io:fwrite("Test exception 1 starting...~n"),
    Result = (catch erlang:foo()),
    io:fwrite("Test exception 1 finished: ~p~n", [Result]),
    ok.

Calling run displays:

Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false]

Test exception 1 starting...
Test exception 1 finished: {'EXIT',
                               {undef,
                                   [{erlang,foo,[]},
                                    {exceptions,run,0},
                                    {init,start_it,1},
                                    {init,start_em,1}]}}

…and the process is still alive.

• Catching an exception with try … catch. The full syntax is something like this:

    try erlang:foo() of
	Any ->
	    Any
    catch
	error:Reason ->
	    io:fwrite("Error reason: ~p~n", [Reason]);
	throw:Reason ->
	    io:fwrite("Throw reason: ~p~n", [Reason]);
	exit:Reason ->
	    io:fwrite("Exit reason: ~p~n", [Reason])
    after
	io:fwrite("Doing some stuff no matter what happened.~n")
    end.

try executes the given function and return it's value (which can be pattern matched) if everything's OK, if an exception is generated it goes in the the matching catch clause. In any case, it then goes inside the after block (similar to finally in Java).

Running the previous code output:

Error reason: undef
Doing some stuff no matter what happened.

(Calling a function that does not exists throws an error)

As everything in Erlang, try … catch returns a value (the executed function, the return the matching clause or the return of the matching exception clause).

Examples

Let see more examples.

-module(exceptions).
-compile([export_all]).

run() ->
    run(1, no_exception, 'catch'),
    run(2, no_exception, 'try'),
    run(3, 'throw', 'catch'),
    run(4, 'throw', 'try'),
    run(5, 'exit', 'catch'),
    run(6, 'exit', 'try'),
    run(7, 'error', 'catch'),
    run(8, 'error', 'try'),
    ok.

run(ID, Exception_type, Handling_type) ->
    io:fwrite("~p) Generating ~p, handled with ~p.~n", [ID, Exception_type, Handling_type]),
    Fun = fun() -> exception(Exception_type) end,
    Result = execute(Handling_type, Fun),
    io:fwrite("~p) Result: ~p~n", [ID, Result]).

exception(no_exception) ->
    ok;
exception('throw') ->
    throw("Throwed exception");
exception('exit') ->
    exit("Exited");
exception('error') ->
    erlang:error("Error generated").

execute('catch', Fun) ->
    (catch Fun());
execute('try', Fun) ->
    try Fun()
    catch
	Error:Reason ->
	    {Error, Reason}
    end.

Output:

1) Generating no_exception, handled with 'catch'.
1) Result: ok
2) Generating no_exception, handled with 'try'.
2) Result: ok
3) Generating throw, handled with 'catch'.
3) Result: "Throwed exception"
4) Generating throw, handled with 'try'.
4) Result: {throw,"Throwed exception"}
5) Generating exit, handled with 'catch'.
5) Result: {'EXIT',"Exited"}
6) Generating exit, handled with 'try'.
6) Result: {exit,"Exited"}
7) Generating error, handled with 'catch'.
7) Result: {'EXIT',{"Error generated",
                    [{exceptions,exception,1},
                     {exceptions,execute,2},
                     {exceptions,run,3},
                     {exceptions,run,0},
                     {init,start_it,1},
                     {init,start_em,1}]}}
8) Generating error, handled with 'try'.
8) Result: {error,"Error generated"}

An interesting thing we can see here is that, in case of an error, catch get a stack trace which can be very useful for debugging but try … catch does not get it.

I prefer try … catch syntax (and it's the recommended way to catch exceptions because you can choose what kind of exceptions you want to catch, catch catches everything) but it's regrettable that it does not return the stack trace.

You can use erlang:get_stacktrace but it returns the stack trace from where you are calling it. If the exception is generated deep inside the function you are calling, get_stacktrace does not gives the root cause of the exception.

Having a stack trace is very useful but it make things a bit slower. I made a simple benchmark:

bench() ->
    Throw_fun1 = fun(_) -> (catch exception('throw')) end,
    Error_fun1 = fun(_) -> (catch exception('error')) end,
    Throw_fun2 = fun(_) -> try exception('throw') catch Error:Reason -> {Error, Reason} end end,
    Error_fun2 = fun(_) -> try exception('error') catch Error:Reason -> {Error, Reason} end end,
    Seq = lists:seq(1, 100000),
    timer:sleep(1000),
    {Time_throw1, _} = timer:tc(lists, foreach, [Throw_fun1, Seq]),
    {Time_error1, _} = timer:tc(lists, foreach, [Error_fun1, Seq]),
    {Time_throw2, _} = timer:tc(lists, foreach, [Throw_fun2, Seq]),
    {Time_error2, _} = timer:tc(lists, foreach, [Error_fun2, Seq]),
    io:fwrite("Throw (catch): ~p micro seconds~n", [Time_throw1]),
    io:fwrite("Error (catch): ~p micro seconds~n", [Time_error1]),
    io:fwrite("Throw (try): ~p micro seconds~n", [Time_throw2]),
    io:fwrite("Error (try): ~p micro seconds~n", [Time_error2]),
    ok.

Results (for 100 000 calls):

Throw (catch): 73920 micro seconds
Error (catch): 169576 micro seconds
Throw (try): 64118 micro seconds
Error (try): 63125 micro seconds

Throwing an error or an exception take the same amount of time but using catch on an error is 2.5 times slower than using try … catch (my quick conclusion on that is because catch generates a stack trace).

I would like having only one way of catching exceptions (no catch, only try … catch) and a way to specify if I want a stack trace or not in case of error. Maybe something like this:

try Fun()
catch
    Error:Reason:Stack ->
        {Error:Reason:Stack}
end.

If a catch clause is waiting for 3 elements (Error, Reason, Stack), the compiler add the necessary stuff to call the Fun with a stack trace. If there are only 2 elements (Error, Reason), keep the actual behavior.

Do we really need exceptions in Erlang?

Exceptions may be useful but we can achieve the same goal in Erlang in other ways. Lots of functions have a signature like: {ok, Value} | {error, Reason}.

Those functions have different outputs between the normal case and the exceptional case. Combined with case we get the same behavior as catching an exception. If we don't use case, we get a badmatch error.

case_way() ->
    Fun = fun(ok) -> {ok, "It works"};
	     (nok) -> {error, "It does not work"}
	  end,
    run_case(1, Fun, ok),
    run_case(2, Fun, nok),
    ok.

run_case(ID, Fun, Arg) ->
    case Fun(Arg) of
	{error, Reason} ->
	    io:fwrite("~p) Error: ~p~n", [ID, Reason]);
	{ok, Value} ->
	    io:fwrite("~p) Value: ~p~n", [ID, Value])
    end.

Running case_way:

1) Value: "It works"
2) Error: "It does not work"

Boons:

• Way much faster than exceptions (around 4 times faster according to my quick bench)
• No specific syntax

Banes:

• Normal case needs some encapsulation like {ok, Value} instead or returning Value directly (not doing so may lead to unknown states if the return is not pattern matched for errors)
• No convention (you can return {exit, Type, Reason} if you want, or anything you want, developer needs to read carefully documentation of each function before using it)

In Joe Armstrong's book, he says that usually people use {error, Reason} when an error occurs quite often and exceptions for less frequent errors. It makes sense, but I do not completely agree with Joe on that matter. When you are developing a software for yourself (or you firm), you may know how your code is used so you know if an error occurs often or not. But when you are developing software for other developers, you don't know how they are going to use it, it's more difficult to "predict" if the error is going to be thrown often or not.

So I tend to prefer throwing exceptions (maybe I have used to much of Java). I think the added syntax is necessary in order to keep thing clear, homogeneous and easy to use. I would love seeing a version of Erlang without functions having a {error, Reason} thing in their return signature (but something like throw(Reason)).

Complete source code associated with this post (you can do whatever you want with it): exceptions.erl

I started using the erlang programming language few months ago. Erlang is a wonderful language if you want to do reliable, distributed, highly concurrent, fault-tolerant, soft-real-time, highly available, hot swapping applications :-).

So, today I will give you a glimpse on one cool functionality of Erlang: the ability to update your code without stopping your application. Here it's just about how it works for a process (the principle is the same for an application except that you have much more things to take into account when you have several thousands process talking to each other).

THE CODE

We are going to use a simple piece of code. We want a server thread listening for messages (each message is printed on the console with a sequence number), and a client thread, sending a message to the server every second. Here is the code (I usually don't use comments but I put some here because you may not understand erlang code):

-module(code_reload). % This is the module declaration.

-export([start_server/0, start_client/1]). % Exporting functions allow them to be called from outside the module.
-export([server_loop/1, client_loop/1]).

start_server() ->
    spawn(?MODULE, server_loop, [0]). % This function calls the server_loop function in a new thread.

server_loop(Count) ->
    receive % Wait for messages
        {From, quit} ->
            io:fwrite("Received quit command from n", [From]),
            ok;
        {From, Message} ->
            io:fwrite("p received message p~n", [Count, self(), Message, From]), % Display the message we received.
            ?MODULE:server_loop(Count); % Call the same function again to wait for an other message.
    	_ ->
            throw(unexpected_message)
    end.

start_client(ServerPid) ->
    spawn(?MODULE, client_loop, [ServerPid]).

client_loop(ServerPid) ->
    receive
        {From, quit} ->
            io:fwrite("Received quit command from n", [From]),
            ok
    after 1000 -> % If no messages were received after 1 second, send a message to the server.
            ServerPid ! {self(), now()},
            ?MODULE:client_loop(ServerPid)
    end.

Let's start an erlang shell:

$ erl
Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false]

Eshell V5.6.2  (abort with ^G)
1> c(code_reload). % This compile the module code_reload.
{ok,code_reload}
2> ServerPid = code_reload:start_server(). % Start the server and assign the server process id to the variable ServerPid.
<0.37.0>
3> ClientPid = code_reload:start_client(ServerPid).
<0.39.0>
0: Server <0.65.0> received message {1211,11183,231032} from <0.67.0>
0: Server <0.65.0> received message {1211,11184,232031} from <0.67.0>
0: Server <0.65.0> received message {1211,11185,233029} from <0.67.0>
0: Server <0.65.0> received message {1211,11186,234031} from <0.67.0>
0: Server <0.65.0> received message {1211,11187,235030} from <0.67.0>

We can see the server printing the messages. But oups, there is a bug! I forgot to increment the counter so each line start with "0" instead of an incrementing number.

Let's change the following line in the code:

?MODULE:server_loop(Count + 1);

We need to go back to the shell and compile the new code:

4> c(code_reload).
{ok,code_reload}
0: Server <0.65.0> received message {1211,11188,236023} from <0.67.0>
0: Server <0.65.0> received message {1211,11189,237031} from <0.67.0>
1: Server <0.65.0> received message {1211,11190,238021} from <0.67.0>
2: Server <0.65.0> received message {1211,11191,239031} from <0.67.0>
3: Server <0.65.0> received message {1211,11192,240018} from <0.67.0>
4: Server <0.65.0> received message {1211,11193,241022} from <0.67.0>
5: Server <0.65.0> received message {1211,11194,242021} from <0.67.0>
6: Server <0.65.0> received message {1211,11195,243031} from <0.67.0>

Ah! It's better, the message number is growing as expected. Notice that the threads are still the same (<0.65.0> for the server and <0.67.0> for the client).

There is no black magic here. The main part of the code is a loop. The server function is server_loop and it calls itself with ?MODULE:server_loop(…). The process is running inside the old version of the code, and when we call server_loop again, the new call is send to the new version of the code.

Be careful, this happens only because we call the function that way ?MODULE:server_loop (code_reload:server_loop also works). Hot upgrade does not work if we call server_loop directly with going through the module again. This allows you to control where and when code reloading is done.

Now we can send a quit message to the client and the server:

5> ClientPid ! {self(), quit}.
Received quit command from <0.30.0>
{<0.30.0>,quit}
6> ServerPid ! {self(), quit}.                     
Received quit command from <0.76.0>
{<0.76.0>,quit}