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

[Eric Newhuis (personal)]

Ok, nice.  But why not leave {error,_} unmatched?  Does erlang:error/1 give better post-mortem?

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
>