[erlang-questions] maps API

Benoit Chesneau bchesneau@REDACTED
Fri Dec 4 11:46:43 CET 2015


i would pre

On Fri, Dec 4, 2015 at 9:23 AM zxq9 <zxq9@REDACTED> wrote:

> On Friday 04 December 2015 05:04:23 Benoit Chesneau wrote:
> > What is the reasoning of throwing an error on `maps:get/2` instead of
> > returning `undefined`? And instead have `maps:find/2`.  I am curious. I
> > would have expected that get like a proplists would return a default set
> to
> > undefined.
>
> I've always wondered why these were not universalized across these
> different modules:
>
>     fetch(Key, Container) -> Value. % or throw exception
>
>     find(Key, Container) -> {ok, Value} | error.
>
>     get(Key, Container) -> get(Key, Value, undefined).
>     get(Key, Container, Default) -> Value | Default.
>
> find/2, as defined above could of course be defined in terms of get/3, and
> the specific names of the functions is a bit arbitrary -- but my point is
> that a bit more consistency would be nice.
>
> It is nice to have one that *always* throws an exception on a miss. Its
> nice to have one that returns a reliable response on a miss. Its nice to
> have one that always returns a custom default on a miss. Its natural to
> crash or carry on without having to wrap calls in try..except or make sure
> that a structure is defined in a way that a stored value will *never* be
> 'error' or 'undefined' or whatever. All three exist in various APIs, but
> its one of those weird cases of "A, B, C" <- pick any two.
>
>
I would have expected to crash on a non matching result instead like
`{error, notfound}` or `{error, bad_map}` rather than raising an exception.

IMO, it's a question of convenience there, since throwing an error remove
the need to match a result (ie. `Value = maps:get(Maps, Key)` instead of
`{ok, Value} = maps:get(Maps, Key)`  . I guess I wanted to confirm it or
maybe there is another reason for it?

- benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151204/5920e734/attachment.htm>


More information about the erlang-questions mailing list