Please Throw that Error
8/25/2008
Development, Rant
(0)
When you do something that should cause an error, you should get an error. That seems like a simple enough rule to follow, yet
in the past three days, I've experienced two instances where I didn't get an error when I should have but rather the app ran
with some rather odd
behavior. Both were small problems that would have been easily fixable had I just gotten an error instead of some unexpected
behavior.
The first instance was when refactoring some of my code into a new class for an XNA game I'm developing.
The way XNA games work (at a very simple level) is by doing a update method then a draw method and then looping until the
conclusion of the game. To draw an object, you need to pass along what texture to use to draw said object with. During my
refactoring, the act of setting this texture to the image I wanted to display went MIA. Thus when I made the draw call, my
texture was NULL.
The behavior I would expect at this point would be for the compiler (or run-time compiler) to scream bloody murder that my
texture is NULL. After all, how can you draw NULL to the screen? Worst case, it should draw nothing and continue on its merry
way. In actuality, the app did something much more strange. It ignored everything left in the draw method and jumped
immediately into the update method.
This caused my app to blow up the next time an object was initialized to start doing my drawing, as the previous object I used
was still open. The error I received now was at a completely different line than what caused it, cleverly hiding it's true
source. It was rather confusing as to why my object for drawing was still open, as I was sure I had closed it each time after
using it. Only when walking through my code line by line did I find that it mysteriously jumped into the update method while
in the middle of a foreach loop.
Had this just thrown a NULL error, I could have fixed it in two minutes rather than spending a bunch of time search for this
mysterious code jump and subsequently blogging about it. I'm still puzzled that it didn't, but I now know what to check for if
I see this behavior again.
The second time I saw this behavior was when working with the ASP.net AJAX UpdatePanelAnimationExtender. Anyone that's worked
much with ASP.net AJAX shouldn't be surprised when weird things happen. Anyways, I use the UpdatePanelAnimationExtender to
display a loading icon when things are loading and then also to disable things like Save buttons while loading is going on.
At some point while working on my app, I removed a button from the page but not from inside the section of the
UpdatePanelAnimationExtender. on any other control (that I know of), if you try and point to a control that doesn't exist,
you're going to get a compile error (and then remove the missing control and recompile successfully). Not so with an
UpdatePanelAnimationExtender.
Instead, the enable/disable action that was applied to this now departed button is applied to all controls inside the
UpdatePanel the UpdatePanelAnimationExtender is targeting. Why would this not cause an error like it would for any other
control? Who knows, but it does, and perplexed me for some time as to my it wanted to disable my whole page at once when it
really should just be doing a couple button controls.
I'll probably submit both these errors to the development teams for AJAX and XNA (one to each, though I suspect the AJAX guys
might get a kick out of other Microsoft technologies also having strange issues that they must see so often) so hopefully no
one else has to go through
the pain I did.
I feel firmly in both these cases that the compiler should have thrown an error either at compile time or
at runtime. The worst thing it could do, which it did do, was work. Both these problem
This article has been view 649 times.
|