<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 16, 2015 at 12:43 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 08/15/2015 04:56 PM, Joe Armstrong wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For a while now I've adopted a convention for naming functions<br>
which I find rather useful, so I thought I'd discuss it here,<br>
(it's a kind of RFC-2119 lite notation :-)<br>
<br>
Rule1: Functions which return {ok,X} | {error,W} are called may_<name><br>
<br>
Rule2: Functions which return a value or raise an exception are called<br>
must_<name><br>
</blockquote>
<br></span>
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.<br>
<br>
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!"<br>
<br>
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).<br>
<br>
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.<br>
<br>
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".<br></blockquote></div><br>Hi!</div><div class="gmail_extra"><br></div><div class="gmail_extra">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: <br></div><div class="gmail_extra">  - efuns must call xfuns wrapped in try/catch<br></div><div class="gmail_extra">  - efuns must call efuns in 'case' or as a return value<br></div><div class="gmail_extra">  - xfuns should call efuns only in 'case'</div><div><br></div><div class="gmail_extra">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. </div><div class="gmail_extra"><br></div><div class="gmail_extra">[*] Dialyzer and typer might be able to infer qualifiers for functions (or report undecidable cases), making it possible to qualify basically only exported functions.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I know I've been bitten by this more than once.</div><div class="gmail_extra"><br></div><div class="gmail_extra">best regards,</div><div class="gmail_extra">Vlad</div><div class="gmail_extra"><br></div></div>