[erlang-questions] I think I wish I could write case Any of whatever -> _ end.

[Ulf Wiger]

On 05/19/2010 03:44 PM, Eric Newhuis (personal) wrote:
> Ok, nice.  But why not leave {error,_} unmatched?  Does erlang:error/1 give better post-mortem?

Actually, it should have been erlang:error(Error, [F]),
and, yes, then it would give a good indication, including
the name of the file that couldn't be opened.

The main purpose of the wrapper, i.e. not calling file:open/2
directly, is that I prefer it to raise an exception rather
than returning an error tuple. This allows me to write the
main program flow as Fd = open(File), rather than case file:open(File,
[read]) of {ok, Fd} -> ...; {error, Reason} -> ... end.

While I could have written

open(F) ->
   case file:open(F, [read]) of
      {ok, Fd} -> Fd;
      Error ->
         erlang:error(Error, [F])
   end.

...that would have lost the info that I know that the
function returns {ok, Fd} | {error, Reason}. I want to
keep that information in the code, without unnecessarily
constructing tuples and binding variables that I don't
care about.

This is a judgement call. Sometimes you really don't want
to match on specifics of the return value(s) that you don't
care about, because you don't want code to break needlessly
due to changes that were not relevant to the code in question.

In this particular pattern, my preference is to
do a partial match, in order to convey as much knowledge as
possible, partly because the function is ubiquitous and its
signature very well understood.

BR,
Ulf W

> 
> On May 19, 2010, at 4:05 AM, Ulf Wiger wrote:
> 
>> On 05/19/2010 05:30 AM, Richard O'Keefe wrote:
>>>
>>> On May 19, 2010, at 3:11 PM, Eric Newhuis (personal) wrote:
>>>
>>>> I appreciate all your comments.
>>>>
>>>> I still don't like temporary variables like X or whatever because they
>>>> contain no semantic quality and there is a tension between short names
>>>> to make the pattern obvious and longer names for reunderstanding.
>>>
>>> The variable name X has been used in the examples,
>>> because the examples have been free of content.
>>> No-one, as far as I am aware, is arguing for the use of X
>>> _as such_, although it is at least better than _  or ~ .
>>>
>>> This is why I keep on screaming for *real* examples.
>>> I predict that in real examples, we can find a way to express
>>> what we want with meaningful variable names.
>>
>> Personally, I quite often use constructs like
>>
>> open(F) ->
>>  case file:open(F, [read]) of
>>     {ok, Fd} -> Fd;
>>     {error,_} = Error ->
>>         erlang:error(Error)
>>  end.
>>
>> Matching the error clause that way not only avoids constructing
>> a tuple needlessly, but also signals that I really don't care
>> /why/ it fails in this particular context - except when debugging,
>> which is why I report it. Raising an exception
>> highlights the fact that I /expect/ it to succeed.
>>
>> Perhaps not the best of examples, but it was the one that came
>> to mind.
>>
>> BR,
>> Ulf W
>> ---------------------------------------------------
>>
>> ---------------------------------------------------
>>
>> WE'VE CHANGED NAMES!
>>
>> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.
>>
>> www.erlang-solutions.com
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
> 

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com