ILoggable

A place to keep my thoughts on programming

March 28, 2007 .net, geek, java, rant , , ,

throws NobodyCaresException

I’ve been doing java again for a project for the last few weeks and it’s been fun. You do get spoiled from the clean syntax C# Properties give you over the getter/setter pattern. And talk about notation differences. I’m so used to Pascal Case on everyting except for fields and parameters that writing Camel Case on methods is taking some getting used to again. And don’t even get me started on switching back and forth between Eclipse and VS.NET several times a day. My muscle memory is in shock. But once you get your mind in the right frame for the idiosyncracies, everything else is so similar is scary, especially with the Java 5.0 additions.

The difference, however, between the two platforms that I was always on the fence about is Checked Exceptions:

In Java, I love that I can declare what exceptions a method may throw and the IDE can pick this up and let you make intelligent decisions. In C#, you have to hope there are some mentions in the docs and otherwise you just find out at runtime and either have a catch all or add individual catches as you find exceptions.

But then, checked exceptions are in my mind the single most responsible party for the good old catch {} gem. And it’s unavoidable. There are a number of cases where a non-type-safe argument is required, which, if it was wrong, would throw an exception. However, most of the time that argument isn’t dynamic, but some constant you define. Really you know that the exception you are forced to handle will never be thrown and you put a catch {} in there, feeling justified. Soon enough the guilt is gone and you start using it when you just don’t feel like dealing with that exception right now. Suddenly you’re swallowing exceptions that someone up the chain might have cared about or that should have legitimately bubbled to the top. Bah.

Being a rabid fan of anything that makes code requirements machine discoverable, not being able to declare my exceptions feels dirty. And even for human discovery, documentation isn’t sufficient, since it only covers the surface level, i.e. what I throw. Now, if i use someone else’s code in there, i need to hope they were also diligent and I have to add any exceptions they may throw and I don’t handle to the ones i may throw. Yeah, thatdocumentation is highly likely to fall behind the reality of the code.

Wouldn’t it be nice if we could declare our exceptions as informational. Like throws but you don’t have to deal with it. Huh, wouldn’t that be meta-data about your code, i.e. a perfect candidate for Attributes ne Annotations? I’ve seen rumblings here and there about this, but nobody’s ever picked it up seriously, that I could find. I for one, would love it if I could say

[Throws("InvalidOperationException,FooBarException")]
public void SomeMethod() { ... }

and have the IDE pick up on it to let me know and optionally generate warnings about things I’m not catching. I think that would be the best of both worlds.

Leave a comment