<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 16, 2015 at 12:18 PM, 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 class="">On 08/16/2015 12:06 PM, Vlad Dumitrescu wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
On Sun, Aug 16, 2015 at 12:43 AM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br></span><div><div class="h5">
<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
<br>
    On 08/15/2015 04:56 PM, Joe Armstrong wrote:<br>
<br>
        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<br>
        may_<name><br>
<br>
        Rule2: Functions which return a value or raise an exception are<br>
        called<br>
        must_<name><br>
<br>
<br>
    The concept is interesting, the implementation is too verbose for<br>
    most people to follow it. That, and having a whole API fit under the<br>
    letter M is not the best idea for documentation.<br>
<br>
    Some languages have function names like open_file! or open_file? and<br>
    so on, with special meanings attached to them (sometimes just a<br>
    convention). We can't do that in Erlang, but something like<br>
    'open_file' for Rule1 and 'open_file!' for Rule2 would be pretty<br>
    explicit. They would be the equivalent of "Please open the file<br>
    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<br>
    something like open_file_ (meh) and open_file@ (not as bad imo).<br>
<br>
    So using something like open_file@ could be interesting. But<br>
    contrary to what I was saying in my email so far, I would suggest<br>
    having open_file be the crash-only version (because I believe it<br>
    fits Erlang programming best) and open_file@ be the one that returns<br>
    errors.<br>
<br>
    If you follow that, you not only know which function may return<br>
    errors, but also you are explicitly requesting errors to be returned<br>
    to your code which means a great deal for clarity, without<br>
    sacrificing the spirit of "let it crash".<br>
<br>
<br>
Hi!<br>
<br>
Having a distinction between functions that throw exceptions (hereby<br>
named xfuns) and those that return error values (hereby named efuns)<br>
makes visible some interesting aspects (I hope I got these right) that<br>
make it easier to spot some coding errors:<br>
   - efuns must call xfuns wrapped in try/catch<br>
   - efuns must call efuns in 'case' or as a return value<br>
   - xfuns should call efuns only in 'case'<br>
</div></div></blockquote>
<br>
Not exactly.<br>
<br>
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.<br>
<br>
Similarly, "xfuns" can call "efuns" with a plain match, expecting them to work and crashing otherwise without having to throw manually.<br>
<br>
The only difference between the two is that "xfuns" succeed or crash, while "efuns" succeed, return an error for expected failures and crash otherwise .<div class="yj6qo ajU"><div id=":w1" class="ajR" tabindex="0"><img class="ajT" src="//ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div></blockquote></div><br>Ah, I see, but Joe mentioned using this for dict:fetch and dict:find, so I assumed it was more general.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In any case, there is more meta-data about functions that would be useful to have, by declaring it or by inferring it or both: is a function pure? does it interact with the environment (files, network, user input)? does it use callbacks (making other meta-data dependent on arbitrary third-party code)? This meta-data has also two "levels": local and global, where the global one is the recursive closure over all callees. All this would be useful, but it gets complicated fast.</div><div class="gmail_extra"><br></div><div class="gmail_extra">best regards,<br></div><div class="gmail_extra">Vlad</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>