[erlang-questions] Any wisdom to offer on "tagged return values"

[mats cronqvist]

 Joe Armstrong <erlang@REDACTED> writes:

> On Wed, May 6, 2009 at 10:41 AM, mats cronqvist <masse@REDACTED> wrote:
>> "Richard O'Keefe" <ok@REDACTED> writes:
>>
>>> On 6 May 2009, at 4:27 am, Ulf Wiger wrote:
>>>> Also, functions that return tagged values don't compose well.
>>>> I've found that I don't use composition that much in my code,
>>>> and I think it's something that one can certainly go overboard
>>>> with. The problem that frequent case matching clutters up the
>>>> code is a bigger issue, IMHO.
>>>
>>> When you are writing code for a specific use,
>>> there's a rule of thumb that I use.
>>> I think it makes sense for library code too.
>>>
>>> Basically, it's "let it crash".
>>>
>>> Spelling it out,
>>>
>>>   - if the immediate caller of a function will know what to
>>>     do with the "exceptional" result, return a tagged value
>>>   - if it won't, so that the code would be cluttered up with
>>>     stuff that just passes the buck, throw an exception.
>>>
>>> For library code, you have to make (informed) guesses about
>>> whether the caller is _likely_ to have anything useful it
>>> can do with the "exceptional" result.
>>
>>  Well put.
>>
>>  Now, the start of this thread was that Kevin was sceptical re this
>>  Programming Rule; "Use tagged return values." I think it's safe to say
>>  that he's right. Following this rule will make you write sub-optimal
>>  code.
>
> I think the rule should be "Use distinguished return values" -

   There are two ways to do it, illustrated by dict:find and dict:fetch.
 The "Programming Rule" ignores this fact. Therefore the rule is bogus.

   mats