cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: [DISCUSS][PROPOSE] use of optional instead of null
Date Sat, 16 Jan 2016 12:56:28 GMT

I completely agree that returning null is bad. Not only does it yield a ton of useless null
checks, it creates leaky abstractions by spreading the handling of the missing case out beyond
the boundary of the class/subsystem.

As a big proponent of the Null Object Pattern [1], I really wanted to like Optional. It is
a great concept in functional languages. So, I tried using it in three (3) different projects
since 2011. In all three systems, I would say that, at best, it was no better than returning
null, and, in other cases, worse. Since Optional.get throws an exception when the wrapped
value is null, all optional accesses must be defensively checked so the code base is littered
with code like the following:

if (value.isPresent()) {
return value.get();

So, basically, you end up replacing null checks and NPEs with isPresent checks and a Guava
exception. As a bonus, when exceptions occurred in production, we had explain the meaning
of them. The quickest explanation — “They are the new NPE”. For all new developers on
the projects, we had one more thing to explain to them which, again, was asking them to do
something differently with no added value. Based on these experiences, I prefer null checks
to optional.

While it is more effort (i.e. more code), I have gone back to using the Null Object Pattern
implemented in this manner [2]. Not only does this approach avoid NPEs, it also explicitly
defines the behavior for the missing case. For more complex examples, it can be unit tested
to ensure the missing case behaves as expected.




John Burwell

d:      +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e: | t: <|%20t:>
    |      w:<>

a:      53 Chandos Place, Covent Garden London WC2N 4HS UK


Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India
LLP is a company incorporated in India and is operated under license from Shape Blue Ltd.
Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under
license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic
of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered
This email and any attachments to it may be confidential and are intended solely for the use
of the individual to whom it is addressed. Any views or opinions expressed are solely those
of the author and do not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender if you believe
you have received this email in error.

On Nov 17, 2015, at 11:16 AM, Daan Hoogland <> wrote:
> LS,
> As a spin off from a discussion in a PR where it is no longer relevant I
> made another PR to show the principle of the use of Optionals[1]
> <>
> Miguel from Schuberg Philis has been proposing this as replacement of the
> bad practice of returning null in methods and I agree. In seldom cases it
> might be more expedient to throw an exception, most notably when a null is
> returned but no check against is done in the calling method. In those cases
> throwing a CloudRuntimeException would be an easier way to go then the
> pattern in this PR. This is a runtime exception however so maybe creating
> an explicit one is more appropriate in those places.
> Anyway I want to propose to move to using the pattern from the PR from now
> on.
> ​[1]​
> ​thoughts?​
> --
> Daan

Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<> |
CSForge – rapid IaaS deployment framework<>
CloudStack Consulting<> | CloudStack Software
CloudStack Infrastructure Support<>
| CloudStack Bootcamp Training Courses<>

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message