<div>Two things I can think of:</div><div><br></div>try / after is useful if you have side effects you need to unwind.<div><br><div>Matching on {ok, ...} is useful when all you really want to do is generate an error -- if something doesn't go as you expect, let it crash, and let a higher level deal with reporting the error to the client.</div>
<div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br clear="all"><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br><div class="gmail_quote">On Thu, Nov 3, 2011 at 6:08 AM, Attila Rajmund Nohl <span dir="ltr"><<a href="mailto:attila.r.nohl@gmail.com">attila.r.nohl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello!<br>
<br>
I have this code (cut out some non-interesting pieces):<br>
<br>
upload_trace_record_file2(Host, Usr, Pwd, RemDir, NetTraceRef) -><br>
    case sftp_client:open(Host, ?SFTP_PORT, Usr, Pwd) of<br>
        {ok, Pid} -><br>
....<br>
            case sftp_client:send(Pid, TRFile, RemTRFile) of<br>
                ok -><br>
                    ok;<br>
                {error, Reason} -><br>
                    {error, sftp_client:format_error(Reason)}<br>
            end,<br>
            sftp_client:close(Pid),<br>
            file:delete(TRFile);<br>
        {error, Reason} -><br>
            {error, sftp_client:format_error(Reason)}<br>
    end.<br>
<br>
update_trace_record_file(TRFile, NetTraceRef) -><br>
    case exml:read_file(TRFile, [{space, normalize}]) of<br>
        {ok, ReadExml} -><br>
            {traceCollecFile, Attributes, ChildList} = ReadExml,<br>
...<br>
            file:write_file(TmpTRFile, TraceText),<br>
            TmpTRFile;<br>
        _ -><br>
            throw({error, bad_xml_file})<br>
    end.<br>
<br>
There are at least two obvious bugs in the error handling (the error<br>
from sftp_client:send is not used; the update_trace_record_file throws<br>
an exception instead of returning an error), but it made think about<br>
how to handle the errors properly in this code. The "let it crash"<br>
philosophy doesn't really work here, because we need to produce a<br>
meaningful error message to the user and the stack trace is not a<br>
meaningful message to them. I was thinking something like this:<br>
<br>
upload_trace_record_file2(Host, Usr, Pwd, RemDir, NetTraceRef) -><br>
    try<br>
        {sftp_client, {ok, Pid}} = {sftp_client,<br>
sftp_client:open(Host, ?SFTP_PORT, Usr, Pwd)},<br>
....<br>
        {sftp_client, ok} = {sftp_client, sftp_client:send(Pid,<br>
TRFile, RemTRFile)},<br>
        sftp_client:close(Pid),<br>
        file:delete(TRFile)<br>
   catch<br>
        error:{badmatch, {sftp_client, Reason}} -><br>
            {error, sftp_client:format_error(Reason)};<br>
        error:{badmatch, {exml, _}} -><br>
                  {error, bad_xml_file}<br>
    end.<br>
<br>
update_trace_record_file(TRFile, NetTraceRef) -><br>
    {exml, {ok, ReadExml}} = {exml, exml:read_file(TRFile, [{space,<br>
normalize}])},<br>
    {traceCollecFile, Attributes, ChildList} = ReadExml,<br>
...<br>
    file:write_file(TmpTRFile, TraceText),<br>
    TmpTRFile.<br>
<br>
but it looks somewhat ugly. Three "assignments" and function calls are<br>
hidden away in tuples, so it's a little hard to read, even though the<br>
rest of the code is simpler. Do you have any other ideas?<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div>