[erlang-questions] Any wisdom to offer on "tagged return values"
Thu May 7 14:59:11 CEST 2009
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
> 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.
More information about the erlang-questions