Comments on: Null Handling Strategies

By: Arcard

Arcard — Thu, 23 Oct 2008 18:05:00 +0000

Занимаюсь дизайном и хочу попросить автора blog.kriskemper.com отправить шаьлончик на мой мыил) Готов заплатить…

By: unlIche

unlIche — Tue, 07 Oct 2008 23:26:59 +0000

Подскажите шооблончег под Wordpress 2.6.2, чтобы был похож на ваш blog.kriskemper.com.

Заранее благодарю)

By: Dave Kirby

Dave Kirby — Tue, 19 Aug 2008 11:49:14 +0000

An alternative is to give the caller the choice. An example is the Python dictionary data type. This lets you access elements in two ways. Firstly you can use the [] syntax, which raises an exception if the element is not in the dictionary. Secondly you can do it via the get method which lets you specify a default value to be returned, and the default value defaults to None (the Python equivalent of null) if it is not specified. i.e. d = {} # create an empty dictionary d['foo'] # raises KeyError d.get('foo') # returns None d.get('foo', 'something') # returns 'something'

By: Bernd Eckenfels

Bernd Eckenfels — Sat, 16 Aug 2008 12:34:00 +0000

Returning null in a case where no result (excpet empty collections) can be expected is quite tollerable for me. However returning null for error cases where nobody expects null returns (for example in factoriey) is dangerous.

I have the rule to require code to state "return null;" in the code and a comment in javadoc when it wants to signal something, and it should never return a variable which can eventually be null.

Blogged about this in german here: http://itblog.eckenfels.net/archives/352-Null-returns-in-Java.html

By: Aaron Erickson

Aaron Erickson — Sat, 16 Aug 2008 03:33:52 +0000

The thing I dont like about solution 2 is that you are using an exception for an unexceptional condition – i.e. many people who live in places like Manhattan, or Wicker Park, dont have cars

That, and we are drilled in our heads as CompSci students that null is a possible condition of every object. That said, some spec that you can put on methods that will at least tell you if a null is possible is a good idea – at least for compile checking to assure that you handle null if that is a possible condition.

That all said, from a design standpoint, null is a PITA. Would rather avoid it where possible – not having it makes things simpler, all things being equal.

By: The Sloth

The Sloth — Sat, 16 Aug 2008 03:26:13 +0000

I would say that your gut feeling was right – NULL is a way to go except the case when you expect a colleciton – then empty collection is a right solution.
Exception will require much more efforts to produce and handle. Also try-catch is a quite expensive operation.
Null object is a classic case of overengineering – you wouldn't need it unless you're already employing few Strategy objects.
There is cleaner Null solution (Resharper catches it perfectly
Car car = carRepository.RetrieveCar(carId)
if(car == null) return;
car.Drive();

All other methods will result in much more hassle.