However, I would argue that returning NullObjects are both a blessing and a curse (pattern/antipattern if you will). On one hand it is good to never have to worry about a method return breaking execution but on the other hand it may lead to unexpected side-effects as demonstrated with the infinite loop seen in this video:
http://www.youtube.com/watch?feature=player_detailpage&v=hp1Y9bhail8

If the user cannot be found (e.g. because incorrect username was entered), this is indeed something exceptional (isn’t supposed to happen with normal application usage), so I think throwing an exception is very appropriate in that case.

Returning a guest user object will indeed not be appropriate in all cases, but it might be in some cases.

You could consider null checking throughout the application code a form of safe programming. However, by doing so you make your code bloated and difficult to maintain (violation of the DRY principle).

You could argue that null checking doesn’t belong in the DAL (if you want to keep your DAL generic in the sense that it is not tailored to particular use-cases or application flows). However, this still is not a good reason to spread null checks thoughout your code. You could handle this elegantly in a seperate layer between your business layer and your DAL.

In short, I think having null checks EVERYWHERE in your code is bad. Having it in one place and one place only is good (whether this is in the DAL or some layer above that).

ALL code should be checking for nulls – I wouldn’t recommend returning a guest object either – If you call GetUser(“Monty”) – and Monty isnt found, then it shouldn’t return a guest object (The method is called Get User – it should either get the user, or nothing).

You cant throw an exception if the user isn’t found, you cant return a guest or empty object, so the only logical solution is to return null – the DAL’s job is to return the user, or nothing at all. Its the business code’s job to translate a null user object into “No one found”