Guice should never ever inject a null value

[gissuebot]

From kevinb9n on February 27, 2007 14:58:17

Right now you can have a custom provider return null and I think guice will
inject the null value.  We should add sanity checking to make sure guice
never injects null.  This way people do not need to check for it in their
constructors etc., which in turn allows them to use null when they want
to in their unit tests (which is quite a helpful ability to have).

Original issue: http://code.google.com/p/google-guice/issues/detail?id=41

[gissuebot]

From limpbizkit on February 27, 2007 21:28:01

I imagine there are scenarios where null is reasonable. Suppose you have a service that checks permissions
against a Guice-provided user. No user might imply non-interactive use, such as by a batch process:

public class AccountService {
  @Inject User user;
  @Inject Customer customer;
  public Account getAccount() {
    Account account = lookupCustomerAccount(customer.getId());
    if(user != null && !account.isViewableBy(user)) {
      throw new InsufficientPermissionsException();
    }
    return account;
  }
}

IMHO, this particular situation doesn't really lend itself to a null-object pattern.

But I do think injecting null is something you'd want to do very rarely. So perhaps instead of banning it
outright, we should make it on-by-default and users could opt-out (like required=false):
  @Inject(nullable=true) User user;

[gissuebot]

From kevinb9n on February 28, 2007 11:17:34

I don't see why a null-object pattern wouldn't work here.  But actually in this case
you don't really want a User at all, you want a ThingThatDecidesPermissions or
PermissionProfile or Authorizations or some such object, and that should never be null.

Null is stinky...

[gissuebot]

From crazyboblee on February 28, 2007 12:24:17

Or an anonymous/guest user. Down with null.

[gissuebot]

From crazyboblee on February 28, 2007 14:45:08

(No comment was entered for this change.)

Labels: 1.0RC3

[gissuebot]

From kevinb9n on March 01, 2007 02:58:35

Fixed with revision 248 .

Status: Fixed