[erlang-questions] Some functions must return values other may do so...

[Loïc Hoguin]

On 08/16/2015 12:06 PM, Vlad Dumitrescu wrote:
>
> On Sun, Aug 16, 2015 at 12:43 AM, Loïc Hoguin <essen@REDACTED
> <mailto:essen@REDACTED>> wrote:
>
>     On 08/15/2015 04:56 PM, Joe Armstrong wrote:
>
>         For a while now I've adopted a convention for naming functions
>         which I find rather useful, so I thought I'd discuss it here,
>         (it's a kind of RFC-2119 lite notation :-)
>
>         Rule1: Functions which return {ok,X} | {error,W} are called
>         may_<name>
>
>         Rule2: Functions which return a value or raise an exception are
>         called
>         must_<name>
>
>
>     The concept is interesting, the implementation is too verbose for
>     most people to follow it. That, and having a whole API fit under the
>     letter M is not the best idea for documentation.
>
>     Some languages have function names like open_file! or open_file? and
>     so on, with special meanings attached to them (sometimes just a
>     convention). We can't do that in Erlang, but something like
>     'open_file' for Rule1 and 'open_file!' for Rule2 would be pretty
>     explicit. They would be the equivalent of "Please open the file
>     thank you very much oh you failed? too bad" and "Open this file! Now!"
>
>     The only thing in that spirit that we can do in Erlang today is
>     something like open_file_ (meh) and open_file@ (not as bad imo).
>
>     So using something like open_file@ could be interesting. But
>     contrary to what I was saying in my email so far, I would suggest
>     having open_file be the crash-only version (because I believe it
>     fits Erlang programming best) and open_file@ be the one that returns
>     errors.
>
>     If you follow that, you not only know which function may return
>     errors, but also you are explicitly requesting errors to be returned
>     to your code which means a great deal for clarity, without
>     sacrificing the spirit of "let it crash".
>
>
> Hi!
>
> Having a distinction between functions that throw exceptions (hereby
> named xfuns) and those that return error values (hereby named efuns)
> makes visible some interesting aspects (I hope I got these right) that
> make it easier to spot some coding errors:
>    - efuns must call xfuns wrapped in try/catch
>    - efuns must call efuns in 'case' or as a return value
>    - xfuns should call efuns only in 'case'

Not exactly.

The way I see it, what you call "efuns" may still crash. Just it 
wouldn't crash on expected failure (ie a file can't be opened). A valid 
crash would be badarg, for example. Returning {error, badarg} when you 
pass an integer instead of a string is not very useful.

Similarly, "xfuns" can call "efuns" with a plain match, expecting them 
to work and crashing otherwise without having to throw manually.

The only difference between the two is that "xfuns" succeed or crash, 
while "efuns" succeed, return an error for expected failures and crash 
otherwise .

-- 
Loïc Hoguin
http://ninenines.eu
Author of The Erlanger Playbook,
A book about software development using Erlang