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

Vlad Dumitrescu vladdu55@REDACTED
Sun Aug 16 12:06:42 CEST 2015

On Sun, Aug 16, 2015 at 12:43 AM, Loïc Hoguin <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".


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'

If a syntactical distinction between xfuns and efuns will prove impractical
(due to too few special characters being available and possible clashes
with existing APIs), an alternative might be to just qualify the functions
at their definition points, either with a keyword or in the -spec
declaration. Unqualified functions are treated as xfuns [*]. Dialyzer and
xref can report calls that break the rules, and actually the compiler can
do that too inside each module. I think that some of the cases would be
caught by dialyzer as "function will never return" errors, but this would
be more precise.

[*] Dialyzer and typer might be able to infer qualifiers for functions (or
report undecidable cases), making it possible to qualify basically only
exported functions.

I know I've been bitten by this more than once.

best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150816/72fd122c/attachment.htm>

More information about the erlang-questions mailing list