I'm writing some Erlang code and I'm very unsure whether I should let everything fail fast. One problem I find with fail fast is that for the developer/user the exception generated is pretty meaningless. Any idea what I should return which would not give esoteric and hard to read stack traces?
Does this means that all the support staff who have to monitor the system should learn how to read Erlang error messages?
Zubair
2010-04-18 14:26:29
Of course everybody whose job it is to diagnose or fix problems need to learn the necessary tools for doing that. Whether that means erlang traces, Python traces, C core dumps, Java traces, or different levels of detail knowledge. You probably want a few specialists for specific technologies, and many generalists who know the basics and can redirect to the appropriate specialists.
ndim
2010-04-18 14:45:11
Ok, thanks. I didn't realise that it is part of the support people's job. I'll let them know. I know they won't be happy though, but it is better for me, as currently they always come to me when there is a production error (about 20 times a day).
Zubair
2010-04-18 16:28:19
The ejabberd FAQ has a list of common error messages: http://www.ejabberd.im/common-errorsI found that quite useful even before I learnt Erlang; I could usually spot key words from the error message I got in that list.
legoscia
2010-04-19 15:16:52
+2
A:
I'd recommend you logging with error_logger(3) and have developer look what actually happens behind the scenes. It's recommended to follow OTP principles in order to collect all data which is returned by VM when process crashes.
Yasir Arsanukaev
2010-04-18 14:24:56
error_logger looks good. So should I call this from the place throwing the exception or the place catching it? And doesn't it mess up the code?
Zubair
2010-04-18 14:31:39
You don't need to call anything. Actually there's no need to do that since you install your logger handler when your program starts.
Yasir Arsanukaev
2010-04-18 14:33:46
There are nice articles on http://spawnlink.com/ which also have an example on using such kind of handlers.
Yasir Arsanukaev
2010-04-18 14:35:24
You would also like http://jkvor.com/log-roller. It is a nice logging module which can be used to collect/view logs from different nodes via your browser. Though I haven't touched it yet.
Yasir Arsanukaev
2010-04-18 14:37:47
Indeed, there was info on gen_event, however OTP principles are described well. When you develop your Erlang application which follows OTP principles, you specify all parameters in config files, these include sasl_error_logger, error_logger_mf_dir. The latter allows you to specify directory to save error log files to. Read more at http://www.erlang.org/doc/man/sasl_app.html. Actually once you configure your app, you'll probably use the same config options in most of your other applications.
Yasir Arsanukaev
2010-04-18 14:57:02
+1
A:
The basic principle in Erlang is:
Make it crash!
I found quite useful to avoid the so called defensive programming. The concept is explained in a bit more detail in the Erlang Programming Rules page:
http://www.erlang.se/doc/programming_rules.shtml#HDR11
Moreover, even if some of the Erlang errors can be a bit cryptic, a nice way to deal with is trace them! Tracing in Erlang is pretty simple. Have a look to this quick reference:
http://aloiroberto.wordpress.com/2009/02/23/tracing-erlang-functions/
or simply refer to the official documentation.
Roberto Aloi
2010-04-18 15:55:03
+1
A:
Since Erlang is a functional language errors are often easily spot if you tend to write Pure functions, because pure function given one arguments will always return the same result. Thus, having the stack trace, once you found the failed function you can figure out what caused an error. Opposed to imperative programming you don't need to spend a lot of time debugging your code, often you don't even need the debugger, and searching the error turns to an interesting game. This article is useful.
Yasir Arsanukaev
2010-04-20 01:37:29