Exception error no function clause matching

Время прочтения
6 мин

Просмотры 21K

Доброй ночи, Хабр! Мы продолжаем изучение Erlang для самых маленьких.

В прошлой главе мы рассмотрели как объявлять функции и как объединять их в модули. В этой главе мы рассмотрим синтаксис функций более подробно.

Исходники примеров к главе лежат здесь.

Сопоставление с образцом

Для начала давайте напишем функцию, которая будет приветствовать пользователя и текст приветствия будет зависеть от его пола. В виде псевдокода наша функция будет выглядеть следующим образом:

function greet(Gender,Name)
  if Gender == male then
    print("Hello, Mr. %s!", Name)
  else if Gender == female then
    print("Hello, Mrs. %s!", Name)
  else
    print("Hello, %s!", Name)
end

Если вместо классической конструкции if then else использовать сопоставление с образцом, можно сэкономить кучу шаблонного кода. Вот так эта функция будет выглядеть на Erlang если использовать сопоставление с образцом:

greet(male, Name) -> 
    io:format("Hello, Mr. ~s!", [Name]);
greet(female, Name) ->
    io:format("Hello, Mrs. ~s!", [Name]).

Функция io:format() используется для форматированного вывода в терминал. Здесь мы использовали сопоставление с образцом в описании списка аргументов функции. Это позволило нам одновременно присвоить входные значения и выбрать ту часть функции, которая должна быть выполнена. Зачем сначала присваивать значения, а потом сравнивать их в теле функции, если можно сделать это одновременно и в «более декларативном» стиле?

В общем виде объявление такой функции выглядит следующим образом:

fnct_name(X) ->
  Extpression;
fnct_name(Y) ->
  Expression;
fnct_name(_) ->
  Expression.

Каждая ветвь функции объявляется как полноценная функция но заканчивается точкой с запятой(;), следом за ней объявляется следующая. После последней части ставится точка.

Обратите внимание на последний образец. Что будет, если мы вызовем нашу функцию greet() и укажем непредусмотренный пол? Мы получим исключение о том, что входные параметры не подходят ни под один из образцов:

1> chapter03:greet(someOther, "Haru").
** exception error: no function clause matching chapter03:greet(someOther, "Haru")

Поэтому важно включать в объявление образец, который подойдет под любое значение. При этом он должен быть последним. В противном случае образцы объявленные после него никогда не будут обработаны.
Давайте перепишем нашу функцию, так что бы она корректно обрабатывала неверные входные значения:

greet(male, Name) ->
    io:format("Hello, Mr. ~s!", [Name]);
greet(female, Name) ->
    io:format("Hello, Mrs. ~s!", [Name]);
greet(_, Name) ->
    io:format("Hello, ~s!", [Name]).

Но сопоставление с образцом в объявлении функций приносит намного больше пользы, чем просто сокращение объема кода. Вспомним списки: список состоит из головы и остальной части. Давайте напишем две функции, которые будут возвращать первый и второй элементы полученного списка.

first([X|_]) -> 
    X.
second([_,X|_) -> 
    X.

Достаточно просто, не так ли? Есть еще один интересный прием, основанный на том факте, что переменные в Erlang можно присвоить только один раз.

same(X,X) ->
    true;
same(_,_) ->
    false.

Эта функция возвращает true, если ее аргументы одинаковы, иначе возвращает false. Как это работает? При вызове функции chapter03::same(one, two). переменной X присваивается значение one, затем производится попытка присвоить этой же переменной значение two. Из-за того, что значение уже было присвоено, попытка заканчивается неудачей и шаблон отбрасывается как неподходящий. Так как во втором случае мы не указываем явно каким переменным нужно присвоить значения, шаблон подходит и функция возвращает false. Если же передать в функцию одинаковые значения chapter03:same(3, 3)., то первый шаблон подойдет и функция вернет true.

Охранные выражения

У сопоставления с образцом есть один большой недостаток: оно недостаточно выразительно. С его помощью нельзя указать тип данных, диапазон и другие подобные обобщения. Каждый образец является конкретным случаем. Для решения этой проблемы в Erlang есть Охранные выражения (или сторожевые условия). Для начала давайте напишем функцию, которая будет принимать наш ИМТ (индекс массы тела) и оценивать наше состояние. ИМТ человека равен его весу разделенному на квадрат роста.

bmi_tell(Bmi) when Bmi =< 18.5 ->
    "You're underweight.";
bmi_tell(Bmi) when Bmi =< 25 ->
   "You're supposedly normal.";
bmi_tell(Bmi) when Bmi =< 30 ->
   "You're fat.";
bmi_tell(_) ->
    "You're very fat.".

Здесь при обращении к функции происходит проверка первого условия, находящегося после слова when (Bmi =< 18.5). Если это выражение возвращает true будет выполнена соответствующая ветвь кода. Иначе происходит проверка следующего условия и так до конца. И тут мы тоже добавили в конец условие, под которое подойдет любое значение.

В общем случае объявление функции с использованием охранных выражений выглядит следующим образом:

fnct_name(Arg_1, Arg_1, ..., Arg_n) when rule_1 ->
    Expression;
fnct_name(Arg_1, Arg_1, ..., Arg_n) when rule_2 ->
    Expression.

Так же мы не ограничены одним выражением в условии. Мы можем провести несколько проверок. Если для прохождения проверки должны быть выполнены оба условия (аналог andalso), между ними ставится запятая(,).

lucky_number(X) when 10 < X, X > 20 ->
    true;
lucky_number(_) ->
    false.

Если достаточно хотя бы одного (аналог orelse), они разделяются точкой с запятой(;).

lucky_atom(X) when X == atom1; X == anot2 ->
    true;
lucky_atom(_) ->
    false.

В охранных выражениях можно использовать функции. Вот функция, которая делит одно число на другое, но перед этим проверяет, что бы переданные аргументы были числами и что бы Y не был равен нулю:

safe_division(X, Y) when is_integer(X), is_integer(Y), Y /= 0 ->
    X / Y;
safe_division(_, _) ->
    false.

Ветвление

Оператор if

Помимо рассмотренных выше выражений в Erlang существует и обычный оператор ветвления if. Давайте перепишем нашу функцию bmi_tell() с использованием этого оператора.

if_bmi_tell(Bmi) ->
    if Bmi =< 18.5 -> "You're underweight.";
       Bmi =< 25   -> "You're supposedly normal.";
       Bmi =< 30   -> "You're fat.";
       true        -> "You're very fat."
    end.

В общем случае оператор ветвления if выглядит следующим образом:

if Rule_1 -> Expression;
   Rule_2 -> Expression;
   ...
   true -> Expression
end.

Хочу напомнить, что в отличии от Haskell, здесь отступы не играют никакой роли кроме декоративной и код отформатирован так только того, что бы его было легче воспринимать. Вы вольны форматировать его так, как вам будет удобно.
Здесь выражения rule_1 и rule_2 — это одно или несколько условий. В случае успешного выполнения условия, будет выполнен блок кода Expression (может содержать одну или несколько команд) идущий за ним. Таких логических ветвей может быть сколько угодно.

Обратите внимание на последний блок true -> "You're very fat.. Что это за условие? Это альтернатива оператору orelse. Блок кода идущий за ним будет выполнен если ни одно условие не пройдет проверку. Важно запомнить, что этот оператор обязателен. Ведь, как мы помним, в Erlang любое выражение должно возвращать результат. Если не описать этот блок, то модуль скомпилируется, но когда поток выполнения проверит все условия и не обнаружит блок true, будет сгенерированно исключение.

** exception error: no true branch found when evaluating an if expression
     in function  chapter03:if_bmi_tell/1 

Оператор case ... of

Помимо if в Erlang есть еще один оператор ветвления — case of. И этот оператор подобен целой функции вставленной в другую функцию. Он позволяет делать выбор не только на основании условия, но так же дает возможность использовать сопоставления с образцом и охранные выражения. В общем виде он выглядит так:

case Rule of
    Val_1 -> Expression;
    Val_2 -> Expression
    ...
    Val_n -> Expression

Здесь Rule — это переменная или выражение, результат которого будет проверяться. Дальше следуют уже знакомые нам блоки «условие — выражение» (Val_1 -> Expression;). В условии можно использовать сопоставления с образцом и охранные выражения, что делает эту конструкцию невероятно гибкой.

Давайте для примера напишем функцию, которая будет принимать кортеж состоящий из температуры и названия шкалы ее измерения и на основании этих данных оценивать ее.

assessment_of_temp(Temp) ->
    case Temp of
        {X, celsius} when 20 =< X, X =< 45 ->
            'favorable';
        {X, kelvin} when 293 =< X, X =< 318 ->
            'scientifically favorable';
        {X, fahrenheit} when 68 =< X, X =< 113 ->
            'favorable in the US';
        _ ->
            'not the best tempperature'
  end.

При выполнении этой функции наш кортеж будет сопоставлен с переменной Temp, затем будет найден паттерн, под который этот кортеж подойдет. Затем будет проведена проверка охранными выражениями и если она будет пройдена — функция вернет соответствующую строку.
Здесь мы так же как и раньше добавляем в конец выражение, которое будет перехватывать все неподошедшие варианты.

Как мы видим, выражение case of почти полностью можно переместить в область объявление функции. Так где же лучше размещать условия? Ответ прост: там где вам больше нравиться. Различия между этими двумя конструкциями минимальны. Поэтому используйте тот вариант, который вам легче читать.

Заключение

В этой главе мы рассмотрели то, как можно управлять потоком выполнения внутри функций. Узнали, какие для этого существуют конструкции и как их использовать. Так же мы познакомились с охранными выражениями.

В следующей главе мы более пристально рассмотрим систему типов в языке Erlang.

Спасибо, что дочитали до конца. Надеюсь, было интересно. Прошу прощения за столь большую задержку. Времени свободного совсем нет.

P.S. Об опечатках и ошибках прошу сообщать в личку, а не в комментарии. Спасибо за понимание.

Not so fast!

There’s no right place for a chapter like this one. By now, you’ve learned enough that you’re probably running into errors, but not yet enough to know how to handle them. In fact we won’t be able to see all the error-handling mechanisms within this chapter. That’s a bit because Erlang has two main paradigms: functional and concurrent. The functional subset is the one I’ve been explaining since the beginning of the book: referential transparency, recursion, higher order functions, etc. The concurrent subset is the one that makes Erlang famous: actors, thousands and thousands of concurrent processes, supervision trees, etc.

Because I judge the functional part essential to know before moving on to the concurrent part, I’ll only cover the functional subset of the language in this chapter. If we are to manage errors, we must first understand them.

Note: Although Erlang includes a few ways to handle errors in functional code, most of the time you’ll be told to just let it crash. I hinted at this in the Introduction. The mechanisms that let you program this way are in the concurrent part of the language.

A Compilation of Errors

There are many kinds of errors: compile-time errors, logical errors, run-time errors and generated errors. I’ll focus on compile-time errors in this section and go through the others in the next sections.

Compile-time errors are often syntactic mistakes: check your function names, the tokens in the language (brackets, parentheses, periods, commas), the arity of your functions, etc. Here’s a list of some of the common compile-time error messages and potential resolutions in case you encounter them:

module.beam: Module name ‘madule’ does not match file name ‘module’

The module name you’ve entered in the -module attribute doesn’t match the filename.

./module.erl:2: Warning: function some_function/0 is unused

You have not exported a function, or the place where it’s used has the wrong name or arity. It’s also possible that you’ve written a function that is no longer needed. Check your code!

./module.erl:2: function some_function/1 undefined

The function does not exist. You’ve written the wrong name or arity either in the -export attribute or when declaring the function. This error is also output when the given function could not be compiled, usually because of a syntax error like forgetting to end a function with a period.

./module.erl:5: syntax error before: ‘SomeCharacterOrWord’

This happens for a variety of reason, namely unclosed parentheses, tuples or wrong expression termination (like closing the last branch of a case with a comma). Other reasons might include the use of a reserved atom in your code or unicode characters getting weirdly converted between different encodings (I’ve seen it happen!)

./module.erl:5: syntax error before:

All right, that one is certainly not as descriptive! This usually comes up when your line termination is not correct. This is a specific case of the previous error, so just keep an eye out.

./module.erl:5: Warning: this expression will fail with a ‘badarith’ exception

Erlang is all about dynamic typing, but remember that the types are strong. In this case, the compiler is smart enough to find that one of your arithmetic expressions will fail (say, llama + 5). It won’t find type errors much more complex than that, though.

./module.erl:5: Warning: variable ‘Var’ is unused

You declared a variable and never use it afterwards. This might be a bug with your code, so double-check what you have written. Otherwise, you might want to switch the variable name to _ or just prefix it with an underscore (something like _Var) if you feel the name helps make the code readable.

./module.erl:5: Warning: a term is constructed, but never used

In one of your functions, you’re doing something such as building a list, declaring a tuple or an anonymous function without ever binding it to a variable or returning it. This warning tells you you’re doing something useless or that you have made some mistake.

./module.erl:5: head mismatch

It’s possible your function has more than one head, and each of them has a different arity. Don’t forget that different arity means different functions, and you can’t interleave function declarations that way. This error is also raised when you insert a function definition between the head clauses of another function.

./module.erl:5: Warning: this clause cannot match because a previous clause at line 4 always matches

A function defined in the module has a specific clause defined after a catch-all one. As such, the compiler can warn you that you’ll never even need to go to the other branch.

./module.erl:9: variable ‘A’ unsafe in ‘case’ (line 5)

You’re using a variable declared within one of the branches of a case ... of outside of it. This is considered unsafe. If you want to use such variables, you’d be better of doing MyVar = case ... of…

This should cover most errors you get at compile-time at this point. There aren’t too many and most of the time the hardest part is finding which error caused a huge cascade of errors listed against other functions.
It is better to resolve compiler errors in the order they were reported to avoid being misled by errors which may not actually be errors at all. Other kinds of errors sometimes appear and if you’ve got one I haven’t included, send me an email and I’ll add it along with an explanation as soon as possible.

No, YOUR logic is wrong!

Logical errors are the hardest kind of errors to find and debug. They’re most likely errors coming from the programmer: branches of conditional statements such as ‘if’s and ‘case’s that don’t consider all the cases, mixing up a multiplication for a division, etc. They do not make your programs crash but just end up giving you unseen bad data or having your program work in an unintended manner.

You’re most likely on your own when it comes to this, but Erlang has many facilities to help you there, including test frameworks, TypEr and Dialyzer (as described in the types chapter), a debugger and tracing module, etc. Testing your code is likely your best defense. Sadly, there are enough of these kinds of errors in every programmer’s career to write a few dozen books about so I’ll avoid spending too much time here. It’s easier to focus on those that make your programs crash, because it happens right there and won’t bubble up 50 levels from now. Note that this is pretty much the origin of the ‘let it crash’ ideal I mentioned a few times already.

Run-time Errors

Run-time errors are pretty destructive in the sense that they crash your code. While Erlang has ways to deal with them, recognizing these errors is always helpful. As such, I’ve made a little list of common run-time errors with an explanation and example code that could generate them.

function_clause

1> lists:sort([3,2,1]). 
[1,2,3]
2> lists:sort(fffffff). 
** exception error: no function clause matching lists:sort(fffffff)
        

All the guard clauses of a function failed, or none of the function clauses’ patterns matched.

case_clause

3> case "Unexpected Value" of 
3>    expected_value -> ok;
3>    other_expected_value -> 'also ok'
3> end.
** exception error: no case clause matching "Unexpected Value"
        

Looks like someone has forgotten a specific pattern in their case, sent in the wrong kind of data, or needed a catch-all clause!

if_clause

4> if 2 > 4 -> ok;
4>    0 > 1 -> ok
4> end.
** exception error: no true branch found when evaluating an if expression
        

This is pretty similar to case_clause errors: it can not find a branch that evaluates to true. Ensuring you consider all cases or add the catch-all true clause might be what you need.

badmatch

5> [X,Y] = {4,5}.
** exception error: no match of right hand side value {4,5}
        

Badmatch errors happen whenever pattern matching fails. This most likely means you’re trying to do impossible pattern matches (such as above), trying to bind a variable for the second time, or just anything that isn’t equal on both sides of the = operator (which is pretty much what makes rebinding a variable fail!). Note that this error sometimes happens because the programmer believes that a variable of the form _MyVar is the same as _. Variables with an underscore are normal variables, except the compiler won’t complain if they’re not used. It is not possible to bind them more than once.

badarg

6> erlang:binary_to_list("heh, already a list").
** exception error: bad argument
     in function  binary_to_list/1
        called as binary_to_list("heh, already a list")
        

This one is really similar to function_clause as it’s about calling functions with incorrect arguments. The main difference here is that this error is usually triggered by the programmer after validating the arguments from within the function, outside of the guard clauses. I’ll show how to throw such errors later in this chapter.

undef

7> lists:random([1,2,3]).
** exception error: undefined function lists:random/1
        

This happens when you call a function that doesn’t exist. Make sure the function is exported from the module with the right arity (if you’re calling it from outside the module) and double check that you did type the name of the function and the name of the module correctly. Another reason to get the message is when the module is not in Erlang’s search path. By default, Erlang’s search path is set to be in the current directory. You can add paths by using code:add_patha/1 or code:add_pathz/1. If this still doesn’t work, make sure you compiled the module to begin with!

badarith

8> 5 + llama.
** exception error: bad argument in an arithmetic expression
     in operator  +/2
        called as 5 + llama
        

This happens when you try to do arithmetic that doesn’t exist, like divisions by zero or between atoms and numbers.

badfun

9> hhfuns:add(one,two).
** exception error: bad function one
in function  hhfuns:add/2
        

The most frequent reason why this error occurs is when you use variables as functions, but the variable’s value is not a function. In the example above, I’m using the hhfuns function from the previous chapter and using two atoms as functions. This doesn’t work and badfun is thrown.

badarity

10> F = fun(_) -> ok end.
#Fun<erl_eval.6.13229925>
11> F(a,b).
** exception error: interpreted function with arity 1 called with two arguments
        

The badarity error is a specific case of badfun: it happens when you use higher order functions, but you pass them more (or fewer) arguments than they can handle.

system_limit

There are many reasons why a system_limit error can be thrown: too many processes (we’ll get there), atoms that are too long, too many arguments in a function, number of atoms too large, too many nodes connected, etc. To get a full list in details, read the Erlang Efficiency Guide on system limits. Note that some of these errors are serious enough to crash the whole VM.

Raising Exceptions

In trying to monitor the execution of code and protect against logical errors, it’s often a good idea to provoke run-time crashes so problems will be spotted early.

There are three kinds of exceptions in Erlang: errors, throws and exits. They all have different uses (kind of):

Errors

Calling erlang:error(Reason) will end the execution in the current process and include a stack trace of the last functions called with their arguments when you catch it. These are the kind of exceptions that provoke the run-time errors above.

Errors are the means for a function to stop its execution when you can’t expect the calling code to handle what just happened. If you get an if_clause error, what can you do? Change the code and recompile, that’s what you can do (other than just displaying a pretty error message). An example of when not to use errors could be our tree module from the recursion chapter. That module might not always be able to find a specific key in a tree when doing a lookup. In this case, it makes sense to expect the user to deal with unknown results: they could use a default value, check to insert a new one, delete the tree, etc. This is when it’s appropriate to return a tuple of the form {ok, Value} or an atom like undefined rather than raising errors.

Now, errors aren’t limited to the examples above. You can define your own kind of errors too:

1> erlang:error(badarith).
** exception error: bad argument in an arithmetic expression
2> erlang:error(custom_error).
** exception error: custom_error

Here, custom_error is not recognized by the Erlang shell and it has no custom translation such as «bad argument in …», but it’s usable in the same way and can be handled by the programmer in an identical manner (we’ll see how to do that soon).

Exits

There are two kinds of exits: ‘internal’ exits and ‘external’ exits. Internal exits are triggered by calling the function exit/1 and make the current process stop its execution. External exits are called with exit/2 and have to do with multiple processes in the concurrent aspect of Erlang; as such, we’ll mainly focus on internal exits and will visit the external kind later on.

Internal exits are pretty similar to errors. In fact, historically speaking, they were the same and only exit/1 existed. They’ve got roughly the same use cases. So how to choose one? Well the choice is not obvious. To understand when to use one or the other, there’s no choice but to start looking at the concepts of actors and processes from far away.

In the introduction, I’ve compared processes as people communicating by mail. There’s not a lot to add to the analogy, so I’ll go to diagrams and bubbles.

Processes here can send each other messages. A process can also listen for messages, wait for them. You can also choose what messages to listen to, discard some, ignore others, give up listening after a certain time etc.

These basic concepts let the implementors of Erlang use a special kind of message to communicate exceptions between processes. They act a bit like a process’ last breath; they’re sent right before a process dies and the code it contains stops executing. Other processes that were listening for that specific kind of message can then know about the event and do whatever they please with it. This includes logging, restarting the process that died, etc.

With this concept explained, the difference in using erlang:error/1 and exit/1 is easier to understand. While both can be used in an extremely similar manner, the real difference is in the intent. You can then decide whether what you’ve got is ‘simply’ an error or a condition worthy of killing the current process. This point is made stronger by the fact that erlang:error/1 returns a stack trace and exit/1 doesn’t. If you were to have a pretty large stack trace or lots of arguments to the current function, copying the exit message to every listening process would mean copying the data. In some cases, this could become unpractical.

Throws

A throw is a class of exceptions used for cases that the programmer can be expected to handle. In comparison with exits and errors, they don’t really carry any ‘crash that process!’ intent behind them, but rather control flow. As you use throws while expecting the programmer to handle them, it’s usually a good idea to document their use within a module using them.

The syntax to throw an exception is:

1> throw(permission_denied).
** exception throw: permission_denied

Where you can replace permission_denied by anything you want (including 'everything is fine', but that is not helpful and you will lose friends).

Throws can also be used for non-local returns when in deep recursion. An example of that is the ssl module which uses throw/1 as a way to push {error, Reason} tuples back to a top-level function. This function then simply returns that tuple to the user. This lets the implementer only write for the successful cases and have one function deal with the exceptions on top of it all.

Another example could be the array module, where there is a lookup function that can return a user-supplied default value if it can’t find the element needed. When the element can’t be found, the value default is thrown as an exception, and the top-level function handles that and substitutes it with the user-supplied default value. This keeps the programmer of the module from needing to pass the default value as a parameter of every function of the lookup algorithm, again focusing only on the successful cases.

As a rule of thumb, try to limit the use of your throws for non-local returns to a single module in order to make it easier to debug your code. It will also let you change the innards of your module without requiring changes in its interface.

Dealing with Exceptions

I’ve already mentioned quite a few times that throws, errors and exits can be handled. The way to do this is by using a try ... catch expression.

A try ... catch is a way to evaluate an expression while letting you handle the successful case as well as the errors encountered. The general syntax for such an expression is:

try Expression of
    SuccessfulPattern1 [Guards] ->
        Expression1;
    SuccessfulPattern2 [Guards] ->
        Expression2
catch
    TypeOfError:ExceptionPattern1 ->
        Expression3;
    TypeOfError:ExceptionPattern2 ->
        Expression4
end.

The Expression in between try and of is said to be protected. This means that any kind of exception happening within that call will be caught. The patterns and expressions in between the try ... of and catch behave in exactly the same manner as a case ... of. Finally, the catch part: here, you can replace TypeOfError by either error, throw or exit, for each respective type we’ve seen in this chapter. If no type is provided, a throw is assumed. So let’s put this in practice.

First of all, let’s start a module named exceptions. We’re going for simple here:

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

throws(F) ->
    try F() of
        _ -> ok
    catch
        Throw -> {throw, caught, Throw}
    end.

We can compile it and try it with different kinds of exceptions:

1> c(exceptions).
{ok,exceptions}
2> exceptions:throws(fun() -> throw(thrown) end).
{throw,caught,thrown}
3> exceptions:throws(fun() -> erlang:error(pang) end).
** exception error: pang

As you can see, this try ... catch is only receiving throws. As stated earlier, this is because when no type is mentioned, a throw is assumed. Then we have functions with catch clauses of each type:

errors(F) ->
    try F() of
        _ -> ok
    catch
        error:Error -> {error, caught, Error}
    end.

exits(F) ->
    try F() of
        _ -> ok
    catch
        exit:Exit -> {exit, caught, Exit}
    end.

And to try them:

4> c(exceptions).
{ok,exceptions}
5> exceptions:errors(fun() -> erlang:error("Die!") end).
{error,caught,"Die!"}
6> exceptions:exits(fun() -> exit(goodbye) end).
{exit,caught,goodbye}

The next example on the menu shows how to combine all the types of exceptions in a single try ... catch. We’ll first declare a function to generate all the exceptions we need:

sword(1) -> throw(slice);
sword(2) -> erlang:error(cut_arm);
sword(3) -> exit(cut_leg);
sword(4) -> throw(punch);
sword(5) -> exit(cross_bridge).

black_knight(Attack) when is_function(Attack, 0) ->
    try Attack() of
        _ -> "None shall pass."
    catch
        throw:slice -> "It is but a scratch.";
        error:cut_arm -> "I've had worse.";
        exit:cut_leg -> "Come on you pansy!";
        _:_ -> "Just a flesh wound."
    end.

Here is_function/2 is a BIF which makes sure the variable Attack is a function of arity 0. Then we add this one for good measure:

talk() -> "blah blah".

And now for something completely different:

7> c(exceptions).
{ok,exceptions}
8> exceptions:talk().
"blah blah"
9> exceptions:black_knight(fun exceptions:talk/0).
"None shall pass."
10> exceptions:black_knight(fun() -> exceptions:sword(1) end).
"It is but a scratch."
11> exceptions:black_knight(fun() -> exceptions:sword(2) end).
"I've had worse."
12> exceptions:black_knight(fun() -> exceptions:sword(3) end).
"Come on you pansy!"
13> exceptions:black_knight(fun() -> exceptions:sword(4) end).
"Just a flesh wound."
14> exceptions:black_knight(fun() -> exceptions:sword(5) end).
"Just a flesh wound."

The expression on line 9 demonstrates normal behavior for the black knight, when function execution happens normally. Each line that follows that one demonstrates pattern matching on exceptions according to their class (throw, error, exit) and the reason associated with them (slice, cut_arm, cut_leg).

One thing shown here on expressions 13 and 14 is a catch-all clause for exceptions. The _:_ pattern is what you need to use to make sure to catch any exception of any type. In practice, you should be careful when using the catch-all patterns: try to protect your code from what you can handle, but not any more than that. Erlang has other facilities in place to take care of the rest.

There’s also an additional clause that can be added after a try ... catch that will always be executed. This is equivalent to the ‘finally’ block in many other languages:

try Expr of
    Pattern -> Expr1
catch
    Type:Exception -> Expr2
after % this always gets executed
    Expr3
end

No matter if there are errors or not, the expressions inside the after part are guaranteed to run. However, you can not get any return value out of the after construct. Therefore, after is mostly used to run code with side effects. The canonical use of this is when you want to make sure a file you were reading gets closed whether exceptions are raised or not.

We now know how to handle the 3 classes of exceptions in Erlang with catch blocks. However, I’ve hidden information from you: it’s actually possible to have more than one expression between the try and the of!

whoa() ->
    try
        talk(),
        _Knight = "None shall Pass!",
        _Doubles = [N*2 || N <- lists:seq(1,100)],
        throw(up),
        _WillReturnThis = tequila
    of
        tequila -> "hey this worked!"
    catch
        Exception:Reason -> {caught, Exception, Reason}
    end.

By calling exceptions:whoa(), we’ll get the obvious {caught, throw, up}, because of throw(up). So yeah, it’s possible to have more than one expression between try and of…

What I just highlighted in exceptions:whoa/0 and that you might have not noticed is that when we use many expressions in that manner, we might not always care about what the return value is. The of part thus becomes a bit useless. Well good news, you can just give it up:

im_impressed() ->
    try
        talk(),
        _Knight = "None shall Pass!",
        _Doubles = [N*2 || N <- lists:seq(1,100)],
        throw(up),
        _WillReturnThis = tequila
    catch
        Exception:Reason -> {caught, Exception, Reason}
    end.

And now it’s a bit leaner!

Wait, there’s more!

As if it wasn’t enough to be on par with most languages already, Erlang’s got yet another error handling structure. That structure is defined as the keyword catch and basically captures all types of exceptions on top of the good results. It’s a bit of a weird one because it displays a different representation of exceptions:

1> catch throw(whoa).
whoa
2> catch exit(die).
{'EXIT',die}
3> catch 1/0.
{'EXIT',{badarith,[{erlang,'/',[1,0]},
                   {erl_eval,do_apply,5},
                   {erl_eval,expr,5},
                   {shell,exprs,6},
                   {shell,eval_exprs,6},
                   {shell,eval_loop,3}]}}
4> catch 2+2.
4

What we can see from this is that throws remain the same, but that exits and errors are both represented as {'EXIT', Reason}. That’s due to errors being bolted to the language after exits (they kept a similar representation for backwards compatibility).

The way to read this stack trace is as follows:

5> catch doesnt:exist(a,4).              
{'EXIT',{undef,[{doesnt,exist,[a,4]},
                {erl_eval,do_apply,5},
                {erl_eval,expr,5},
                {shell,exprs,6},
                {shell,eval_exprs,6},
                {shell,eval_loop,3}]}}

• The type of error is undef, which means the function you called is not defined (see the list at the beginning of this chapter)
• The list right after the type of error is a stack trace
• The tuple on top of the stack trace represents the last function to be called ({Module, Function, Arguments}). That’s your undefined function.
• The tuples after that are the functions called before the error. This time they’re of the form {Module, Function, Arity}.
• That’s all there is to it, really.

You can also manually get a stack trace by calling erlang:get_stacktrace/0 in the process that crashed.

You’ll often see catch written in the following manner (we’re still in exceptions.erl):

catcher(X,Y) ->
    case catch X/Y of
        {'EXIT', {badarith,_}} -> "uh oh";
        N -> N
    end.

And as expected:

6> c(exceptions).
{ok,exceptions}
7> exceptions:catcher(3,3).
1.0
8> exceptions:catcher(6,3).
2.0
9> exceptions:catcher(6,0).
"uh oh"

This sounds compact and easy to catch exceptions, but there are a few problems with catch. The first of it is operator precedence:

10> X = catch 4+2.
* 1: syntax error before: 'catch'
10> X = (catch 4+2).
6

That’s not exactly intuitive given that most expressions do not need to be wrapped in parentheses this way. Another problem with catch is that you can’t see the difference between what looks like the underlying representation of an exception and a real exception:

11> catch erlang:boat().
{'EXIT',{undef,[{erlang,boat,[]},
                {erl_eval,do_apply,5},
                {erl_eval,expr,5},
                {shell,exprs,6},
                {shell,eval_exprs,6},
                {shell,eval_loop,3}]}}
12> catch exit({undef, [{erlang,boat,[]}, {erl_eval,do_apply,5}, {erl_eval,expr,5}, {shell,exprs,6}, {shell,eval_exprs,6}, {shell,eval_loop,3}]}). 
{'EXIT',{undef,[{erlang,boat,[]},
                {erl_eval,do_apply,5},
                {erl_eval,expr,5},
                {shell,exprs,6},
                {shell,eval_exprs,6},
                {shell,eval_loop,3}]}}

And you can’t know the difference between an error and an actual exit. You could also have used throw/1 to generate the above exception. In fact, a throw/1 in a catch might also be problematic in another scenario:

one_or_two(1) -> return;
one_or_two(2) -> throw(return).

And now the killer problem:

13> c(exceptions).
{ok,exceptions}
14> catch exceptions:one_or_two(1).
return
15> catch exceptions:one_or_two(2).
return

Because we’re behind a catch, we can never know if the function threw an exception or if it returned an actual value! This might not really happen a whole lot in practice, but it’s still a wart big enough to have warranted the addition of the try ... catch construct in the R10B release.

Try a try in a tree

To put exceptions in practice, we’ll do a little exercise requiring us to dig for our tree module. We’re going to add a function that lets us do a lookup in the tree to find out whether a value is already present in there or not. Because the tree is ordered by its keys and in this case we do not care about the keys, we’ll need to traverse the whole thing until we find the value.

The traversal of the tree will be roughly similar to what we did in tree:lookup/2, except this time we will always search down both the left branch and the right branch. To write the function, you’ll just need to remember that a tree node is either {node, {Key, Value, NodeLeft, NodeRight}} or {node, 'nil'} when empty. With this in hand, we can write a basic implementation without exceptions:

%% looks for a given value 'Val' in the tree.
has_value(_, {node, 'nil'}) ->
    false;
has_value(Val, {node, {_, Val, _, _}}) ->
    true;
has_value(Val, {node, {_, _, Left, Right}}) ->
    case has_value(Val, Left) of
        true -> true;
        false -> has_value(Val, Right)
    end.

The problem with this implementation is that every node of the tree we branch at has to test for the result of the previous branch:

This is a bit annoying. With the help of throws, we can make something that will require less comparisons:

has_value(Val, Tree) -> 
    try has_value1(Val, Tree) of
        false -> false
    catch
        true -> true
    end.

has_value1(_, {node, 'nil'}) ->
    false;
has_value1(Val, {node, {_, Val, _, _}}) ->
    throw(true);
has_value1(Val, {node, {_, _, Left, Right}}) ->
    has_value1(Val, Left),
    has_value1(Val, Right).

The execution of the code above is similar to the previous version, except that we never need to check for the return value: we don’t care about it at all. In this version, only a throw means the value was found. When this happens, the tree evaluation stops and it falls back to the catch on top. Otherwise, the execution keeps going until the last false is returned and that’s what the user sees:

Of course, the implementation above is longer than the previous one. However, it is possible to realize gains in speed and in clarity by using non-local returns with a throw, depending on the operations you’re doing. The current example is a simple comparison and there’s not much to see, but the practice still makes sense with more complex data structures and operations.

That being said, we’re probably ready to solve real problems in sequential Erlang.

• < Previous
• Index
• Next >

Dear %username%,

Let’s continue learning Erlang for the little ones.

In the previous post we’ve reviewed the way of declaring functions and uniting them into modules. In this post we’ll consider the syntax of functions in details.

The source code of all the examples in this post is here.

Pattern Matching

To begin with, let’s write a function that will greet a user and the welcome text will depend on user’s gender. In the form of the pseudo code our function will look like the following:

function greet(Gender,Name)
  if Gender == male then
    print("Hello, Mr. %s!", Name)
  else if Gender == female then
    print("Hello, Mrs. %s!", Name)
  else
    print("Hello, %s!", Name)
end

If we use pattern matching instead of the classic if then else construction, we can save plenty of the template code. That’s how this function will look in Erlang when using pattern matching:

greet(male, Name) -> 
    io:format("Hello, Mr. ~s!", [Name]);
greet(female, Name) ->
    io:format("Hello, Mrs. ~s!", [Name]).

We use io:format() function for the formatted output to the terminal. Here we used pattern matching in the function argument list. This allowed us to assign the input values and chose that part of the function to be executed at the same time. Why would we first assign values and compare them in the function body later if we can do it concurrently and in a “more declarative” style?

In general terms such declaration looks like the following:

fnct_name(X) ->
  Extpression;
fnct_name(Y) ->
  Expression;
fnct_name(_) ->
  Expression.

We declare each branch as a full-fledged function, but there’s a semicolon at the end of it. Then we declare the next function and use a period after the last part.

Pay attention to the last pattern. What’s going to happen if we call greet() function and pass the unknown gender? We’ll get an exception saying that the input parameters do not match any of the patterns:

1> chapter03:greet(someOther, "Haru").
** exception error: no function clause matching chapter03:greet(someOther, "Haru")

That’s why it’s important to include declaration that will match any value. Besides, it should always be the last one. Otherwise we will never process the patterns declared after it.

Let’s rewrite our function so that it would process properly the incorrect input values:

greet(male, Name) ->
    io:format("Hello, Mr. ~s!", [Name]);
greet(female, Name) ->
    io:format("Hello, Mrs. ~s!", [Name]);
greet(_, Name) ->
    io:format("Hello, ~s!", [Name]).

But pattern matching in declaring functions brings much more benefits than just reducing the code length. Let’s recall lists. A list consists of a head and the remaining part. Let’s write two functions that will return the first and the second elements of a list.

first([X|_]) -> 
    X.
second([_,X|_) -> 
    X.

Quite simple, isn’t it? There’s another interesting method based on the fact that we can assign variables just once.

same(X,X) ->
    true;
same(_,_) ->
    false.

This function returns true if its arguments are the same. Otherwise it returns false. How does it work? When calling chapter03::same(one, two) function we assign one value to X variable. Then we try to assign two to this variable. Since the value has already been assigned, the try fails and the template is rejected as unmatched. In the second case we do not indicate, which variables we should assign values to. Therefore, the pattern is matched and the function returns false. But if we pass the same values chapter03:same(3, 3), the first pattern will match and the function will return true.

Guards

The pattern matching has one big drawback. It’s insufficiently expressive. For instance, we can not specify the data type, a range and some other things with the help of it. Each pattern is an individual case. There are Guard clauses in Erlang to solve this problem. First of all, let’s write a function that will accept our body mass index and estimate our condition. The body mass of a person is his weight divided by the squared height.

bmi_tell(Bmi) when Bmi =< 18.5 ->
    "You're underweight.";
bmi_tell(Bmi) when Bmi =< 25 ->
   "You're supposedly normal.";
bmi_tell(Bmi) when Bmi =< 30 ->
   "You're fat.";
bmi_tell(_) ->
    "You're very fat.".

When referring to the function, we check the first condition after when (Bmi =< 18.5). If the expression returns true, the appropriate code path will be executed. Otherwise we perform the check of the next condition and do the same till the end of the code. At the end we’ll add a condition that will fit any value.

In the general case declaring of the function using guards looks like the following:

fnct_name(Arg_1, Arg_1, ..., Arg_n) when rule_1 ->
    Expression;
fnct_name(Arg_1, Arg_1, ..., Arg_n) when rule_2 ->
    Expression.

We are not restricted to just one expression in the condition. We can perform multiple checks. If we want both conditions to pass (analog of andalso) to perform the check, we should place a comma (,) between them.

lucky_number(X) when 10 < X, X > 20 ->
    true;
lucky_number(_) ->
    false.

If at least one condition (analog of orelse) is enough, we separate them with a semicolon (;).

lucky_atom(X) when X == atom1; X == anot2 ->
    true;
lucky_atom(_) ->
    false.

We can also use functions as guards. Here’s the function that divides one number by another one, but before it checks that the passed arguments were numbers and Y was not zero.

safe_division(X, Y) when is_integer(X), is_integer(Y), Y /= 0 ->
    X / Y;
safe_division(_, _) ->
    false.

Expressions

If Statement

Apart from the considered above expressions, there’s also a regular conditional if expression in Erlang. Let’s rewrite bmi_tell() function using it.

if_bmi_tell(Bmi) ->
    if Bmi =< 18.5 -> "You're underweight.";
       Bmi =< 25   -> "You're supposedly normal.";
       Bmi =< 30   -> "You're fat.";
       true        -> "You're very fat."
    end.

In the general case conditional if expression looks the following way:

if Rule_1 -> Expression;
   Rule_2 -> Expression;
   ...
   true -> Expression;
end.

Reminding you that unlike in Haskell, standoffs are of no importance here, except for being decorative. We’ve formatted the code just to make it clearer. You’re free to format it the way you like.

Rule_1 and Rule_2 expressions here are either one or more conditions. If the condition evaluates successfully, we’ll execute the Expression code block (it may contain one or several commands). You can have as many as you want of such branches.

Please pay attention to the last block: true -> «You’re very fat.». What kind of condition is it? It’s the alternative of orelse statement. The code block following it will be evaluated if none of the conditions pass the check. You should not forget to use this statement, since any expression in Erlang should return a result. If we do not describe this block, the module will compile anyway. But when the execution thread checks all conditions and will not find true block, it will generate an exception.

** exception error: no true branch found when evaluating an if expression
     in function  chapter03:if_bmi_tell/1 

case… of Expression

Besides if, there’s one more conditional expression in Erlang – case of. It’s like a function included into another one. It allows making a choice not only on the basis of a condition, but by using pattern matching and guards. It will look like the following way:

case Rule of
    Val_1 -> Expression;
    Val_2 -> Expression
    ...
    Val_n -> Expression

Rule here is a variable or an expression, the result of which we will check later. Then follow the already familiar “condition-expression” blocks (Val_1 -> Expression;). In conditions we can use pattern matching and guard expressions, which make this construction extremely flexible.

As an example, let’s write a function that will accept a tuple consisting of the temperature and the name of the measurement scale. We will estimate it on the basis of these data.

assessment_of_temp(Temp) ->
    case Temp of
        {X, celsius} when 20 =< X, X =< 45 ->
            'favorable';
        {X, kelvin} when 293 =< X, X =< 318 ->
            'scientifically favorable';
        {X, fahrenheit} when 68 =< X, X =< 113 ->
            'favorable in the US';
        _ ->
            'not the best tempperature'
  end.

When executing this function, our tuple will be compared to Temp variable and then we will find another pattern this tuple will fit. After that we will perform a check by guard expressions. If it’s successful – the function will return the appropriate string.

As well as before, we add an expression to the end. It will intercept all unsuitable variants.

As you can see, we can move case of expression almost in full to the area of declaring the function. So what is the preferable place to locate conditions? The answer is simple: place it wherever you like. Differences between these two constructions are minimal. Therefore, you should use the variant that is more clear for reading.

Summary

In this article we’ve reviewed the way of controlling the execution thread inside functions. We’ve also found out that there are several constructions for that purpose and learnt the way of using them. We also got familiar with guard expressions.

In the next article we’ll review the type system in Erlang.

Thank you for reading the post. Hope it’s been interesting. Please, share it with your friends.