On Tue, Jun 5, 2012 at 1:20 PM, Mark Derricutt <m...@talios.com> wrote:
> On 6/06/12 2:57 AM, Cédric Beust ♔ wrote: > > JQuery does the same thing: selectors return arrays of matching elements, > but if no elements were found, you receive an empty array instead of null. > Anyone who thinks this is a better idea hasn't practically worked with the > concept. > > Failing fast (with an NPE or, in the case above, with a Javascript error > regarding 'undefined') saves much more time than silently proceeding with > an unexpected result. > > Isn't this variation the one we WANT tho - the normal case it returns an > array, but it returns EMPTY when nothing is found, rather than null. > Given the contract says "i return 0 or more found things" thats preferred > IMHO. getElementById() silently returning null however.... > Absolutely, and sadly, the Java collections make this mistake in various places (returning null instead of empty collections). In an ideal world, the default case never crashes (empty collections) but the language gives me a way to crash immediately if I receive null/None/Nothing (without me having to explicitly test for it). > If we had Option<>'s here I'd say "get" methods throw exceptions when failing, > "find" variations return an Option<?> of whatever. Yes, this would make Option much more useful in my opinion. -- Céric -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
