[erlang-questions] Erlang style question - input handling

[Christian S]

On 9/28/06, Nohl Attila Rajmund <attila.rajmund.nohl@REDACTED> wrote:
> Unfortunately I can't change the caller interface. Crashing would be
> also a bad solution, because it's a kind of user input validation and
> the user prefers a nice error dialog over an Erlang crash dump.

This argument is as good as for someone programming in Java saying:

"Using java exceptions for error handling would be a bad solution,
because the user prefers a nice error dialog over an exception stack
trace."

Error handling in erlang is very focused around supervisor processes
trapping crashed processes that it is monitoring/linked to. (The
connection to java exceptions is that printing a stack trace is an
explicit choice in the exception handler.)

The idea with exceptions is that you only program for the situations
that you expect, if you find something unexpected, stop doing things
immediately.

http://en.wikipedia.org/wiki/Crash-only_software


When handling user input one often expect invalid input and want to
give the user another chance to input it again correctly. For example,
a submitted html form: if there is anything wrong then one typically
want to output the form again with the user's previous inputs and with
help text next to the erroneous fields.
An expected error.

If the user input is valid and one then try to store the data in
mnesia but the mnesia transaction returns {aborted, node_on_fire} then
that is an unexpected error. Let it crash. Yaws will trap the crash
and serve the user with an internal server error http response.
An unexpected error.



Handling the unexpected error is easy to answer, just cause an exception.
It is natural to program for this in erlang. A line like
     {atomic, Result} = mnesia:transaction(Fun)
will cause a bad match exceptoin if the return value doesnt match.


Handling the expected error is domain specific for how one want to
proceed in the valid and invalid case.


PS.
Is your use of macros for error codes a C programmer-ism?
Erlang has a perfectly fine data type for error codes: The atom.

I know some people use macros to catch miss spelled names.

PS2.
Writing this, I realize there is a lot to write about errors in
software engineering. Perhaps just to establish a well defined
terminology. The case i describe as an expected error is a user
mistake. The node on fire is really a system design error, lack of
redundancy  (im not accusing mnesia of that crime though :-).