Failing to Fail Early

A coworker and I stumbled across some weird behavior with NHibernate today that totally surprised me. I come from the Hibernate world which tends to be about a version to a version and a half ahead of NHibernate. So I'm used to going to look for excellent support for stored procedures and realizing I'm SOL.

Today though we found an issue that wasn't lack of support, but just a horrible design decision that differs between the two frameworks. In a nutshell, Session.Load was being called with an ID that didn't exist and we weren't receiving an exception. Huh? The difference between Get and Load in my mind was always, same behavior if the PK passed in exists in the database, if it doesn't Get returns null silently, and Load throws ObjectNotFoundException, violently alerting you that your PK is not what you think it is. In this case we were getting back a proxied object that would immediately throw ObjectNotFoundException whenever one of it's getter methods were called. Nice. I assumed that we were misusing the Interceptor functionality or something to cause this but a little googlage revealed this description of the ObjectNotFoundException class in the NHibernate docs:

"Thrown when ISession.Load() fails to select a row with the given primary key (identifier value). This exception might not be thrown when Load() is called, even if there was no row on the database, because Load() returns a proxy if possible..."

Come again? What use do I have for a proxied object that is just going to throw ObjectNotFoundException the moment I start accessing it? Even worse, what if I have a business method that checks a private attribute for null on this object. You shouldn't be able to do anything to this object because according to the database IT DOESN'T EXIST. When all else fails, go to the pragmatic programmers for advice and listen when they tell you to FAIL EARLY. Give me null or give me exceptions, don't fool me into thinking my row is there when it isn't.

The Long and Winding Road

I've started back up on a new phase of a project and it's rekindling my hatred for extensive documentation. I'm beginning to feel that most developers are just not inherently good at writing documentation, myself especially. We're just not wired that way and I think people generally despise doing tasks that they are not good at.

In this instance maybe it's just more painful because there is no challenge involved. It's a straight migration of an existing system so there is none of the excitement involved in finding out what the business domain entails and trying to mate technologies to the problems facing the users of the system.

Luckily we're always running an Agile project at QSI, and this particular client is open to documenting only what is needed and not wasting money on anything more. Unfortunately this brings up the question, what are the bare essentials when it comes to documenting a system? In this instance specifically, what is the minimum amount of documentation needed to capture the state of an existing code base? How valuable is any documentation? It's always the first thing thrown out the door when timelines get compressed and it's typically the last thing updated after maintenance or enhancements are performed on a system.