Skip to content

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.

  • in rant
  • 1 min read

Joe Jobbed

Looks like claassen.net got Joe jobbed. For the past two weeks or so some bastard spammer has been using claassen.net as their return-address domain. And so i've been getting a lot of bounce mails from all over the world. Fun.

First thing, of course, i made sure I wasn't compromised and my hosts was actually being used for the spam. From examining the headers of the messages bounced to me, it looks like the originating hosts are a bunch of zombies, so there isn't even any use in contacting the owners of the hosts that sent the spam.

For now, i'm just going to sit tight and filter incoming messages. Hopefully, the next rev of the zombie moves on to some other unlucky domain owner. And equally hopefully, i won't be on some blacklist because someone didn't check the origination of the spam. Ho hum.

Heisenberg and Properties

There are two reasons that I'm using log4net with increasing, rather than decreasing frequency, despite the excellent debugger in VS.NET:

  1. When doing multithreaded programming, it lets me more easily see what threads are doing in parallel
  2. Heisenberg's Uncertainty Principle as it it relates to Properties

Let me expand on 2)... The Uncertainly Principle, simply put, states that the act of observation changes the observed. Now, he was talking about electrons, but when using the debugger in VS.NET this very principle can really come to bite you. The problem is that Properties do not have to be mere member variable accessors. They can have all sorts of logic attached. You may consider it bad form to have the act of observation (read: the getter) enact some sort of write behavior, and that is a position worth arguing. But even a simple "lazy load" put inside a getter can alter the behavior of the object if executed outside the normal flow.

And that's precisely what happens when you start stepping into the Debugger. Unlike Methods, Properties are shown by default and therefore cause execution of the getter. So if you have a problem with some internal value not being properly set when you run your program, but it being set, if you step through it, look at your Properties.

Now, how does log4net help this? It's still going to cause the getter to fire! Well, in some circumstances yes, but in many others, the reason you are getting this behavior is because the debugger fires all getters, not just the ones you want to look at, likely causing the problem via some part of code you really don't want to be firing off at the time of observation.