For quite a while, I've been wanting to add a method to sys::Map that does a "checked get", where if the key isn't mapped, then you get a exception. Something like this:
map[key] ?: throw Err("Key not mapped: $key")
Although we'd actually use containsKey to handle null values properly.
Definitely a useful method, but hard to come up with a good simple name. Current ideas:
require
obtain
getRequired
Favorite so far is just call it require, but any other ideas?
SlimerDudeTue 6 Mar 2012
From the list, getRequired has my vote.
I thought of something like
map[key, true] = value
to be consistent with other checked methods, but thinking about it, it actually makes no sense! So, err, forget about that!
dobesvWed 7 Mar 2012
You already have getOrAdd, how about getOrThrow ? Likes:
Fits an existing pattern (xOrY)
Starts with "get" so it goes near get and getOrAdd in the docs
Very explicit about what it does, you probably don't have to check the docs to figure out the difference from a plain get.
I don't like require and obtain because they don't start with get and may not even make people think they simply get something if they've never seen them before.
I'd expect that the new "checked get" method will throw an exception iff !containsKey(key). This is different from get(key) == null both for null values and for maps with a non-null def field.
andyWed 7 Mar 2012
I had considered getOrThrow as well - that is probably the most "semantic" choice. So +1.
brianFri 9 Mar 2012
I don't love getOrThrow, but can certainly live with that choice. It does nice effect of showing up in docs right next to get so makes it easily discoverable. I pushed this change
brian Tue 6 Mar 2012
For quite a while, I've been wanting to add a method to
sys::Map
that does a "checked get", where if the key isn't mapped, then you get a exception. Something like this:Although we'd actually use containsKey to handle null values properly.
Definitely a useful method, but hard to come up with a good simple name. Current ideas:
Favorite so far is just call it
require
, but any other ideas?SlimerDude Tue 6 Mar 2012
From the list,
getRequired
has my vote.I thought of something like
to be consistent with other checked methods, but thinking about it, it actually makes no sense! So, err, forget about that!
dobesv Wed 7 Mar 2012
You already have
getOrAdd
, how aboutgetOrThrow
? Likes:get
andgetOrAdd
in the docsI don't like
require
andobtain
because they don't start with get and may not even make people think they simply get something if they've never seen them before.qualidafial Wed 7 Mar 2012
We have a winner! +1
SlimerDude Wed 7 Mar 2012
getOrThrow
returns a +1 for me!StephenViles Wed 7 Mar 2012
I'd expect that the new "checked get" method will throw an exception iff
!containsKey(key)
. This is different fromget(key) == null
both for null values and for maps with a non-nulldef
field.andy Wed 7 Mar 2012
I had considered
getOrThrow
as well - that is probably the most "semantic" choice. So +1.brian Fri 9 Mar 2012
I don't love
getOrThrow
, but can certainly live with that choice. It does nice effect of showing up in docs right next toget
so makes it easily discoverable. I pushed this change