Culture shock

Have I ever mentioned that I hate checked exceptions? I mean, it’s not bad when a method declares that it throws one exception type, but I’ve run across methods that throw no less than four different types of exceptions, with no common superclass between them (except Execption, no pun intended).

I’m in uncharted territory here, seeing as I’m not a hotshot Java coder, so I don’t know if this is like the worst possible thing to do. However, there are cases when there really is nothing I want to do when an exception occurs, but propagating it isn’t really a good idea either, so I’d like to swallow the exceptions and possibly log them. However, swallowing four different types looks more than a bit silly, so I ended up doing this:

} catch (Exception e) {
    if(e instanceof RuntimeException)
        throw e; // My inner C# programmer screams bloody murder at me here...

    // log error, or don't

… because I don’t want four empty catch blocks, but I really don’t want to swallow runtime exceptions either.

So. Am I off my rocker?

Also, a bit nervous…

I’ve been taking university comp sci courses on the side since September. So far I’ve only completed the Intro to Comp Sci that was mostly essay writing and familiarizing oneself with the different aspects of CS. Tomorrow, however, is my first exam. The course is Intro to Databases, and while I’m fairly proficient at getting database work done, I’m nowhere near certain I’ll get a good grade from the exam.

First of all, the course was a web course, so no conversation, no teaching and very little commitment from me. Second, the terminology doesn’t quite map with what I’ve grown used to — in part because it’s in Finnish and in part because I tend to think in SQL, not relational algebra.

I’m fairly certain I’ll pass, but I’d really like to get a good grade, because it affects my chances to apply to the university. I’ve got four more courses, and if my marks are high enough, I just might get in.

Oh well, better not fret, I guess I’ll just go through the old exams again once or twice for practice and then see where I end up. 🙂

JSON update, MonoRail musings

Well, the path expression bits I grafted on to Json.NET are now relatively functional, although in terms of code quality, not much to write home about. I added a rule that says, basically, if the first call is “include” then the mode is “exclude by default” and vice versa. My MonoRail controllers currently use the serializer like so:


where “list” is an enumerable of something that holds a reference to a Foo. The resulting JSON looks something like this:

[{Foo: {Id: 1}}, {Foo: {Id: 2}}]

“Json” is a property that holds a “JsonRenderer” which is just a helper that holds a reference to both the serializer and the controller, so we can append the Render() call there.

All in all I’m pretty pleased with this, because it gives me fine-grained control over serialization, and I can nix the dependency between my domain model and Json.NET (which existed purely because I used JsonIgnoreAttribute on a couple of domain classes).

(As for any aspirations to release my changes — I haven’t had the opportunity to ask for a permission, and to be honest, the overall quality of the extension is “good enough for me” but I’d rather not show it to anyone else just yet. 🙂 Once I’m done with the important bits — that is, the application itself — I might try wrapping them up in a form that leaves the original serializer untouched.)

After managing to simplify the serialization, I noticed that a big part of my controller code looks like this:

public void SomeMethod(long fooId)
 Foo foo = FooDAO.Get(fooId);
 // ...

so I figured I should probably do something about that, too. Fortunately, writing a custom data binder for MonoRail is fairly painless.

Now, the same code would look like this:

public void SomeMethod([DAODataBind] Foo foo)

The binder by default looks for an id parameter, the name is determined by the parameter name so “foo” is looked up based on “fooId”. The attribute has a second form, [DAODataBind(“fooBarId”)] which uses the parameter “fooBarId” instead.

The implementation is a bit of Reflection voodoo. First, we use the supplied ParameterInfo to find out the type of the parameter. If it’s not one of our domain model classes, tough luck, but I have a nice exception for you. Next, we dig up the appropriate DAO from our DAOFactory which comes with a handy GetDAO(Type t) method. Finally we invoke the Get method of the DAO with the id parameter, and return the retrieved object.

Surprisingly enough, that worked very nearly on the first try — I made some assumptions about Type.GetMethod(), mostly the BindingFlags that I’d have to use, but once that was sorted out it worked like a champ.

Overall I’m impressed of how easy MonoRail has been to use and extend. At first, the lack of documentation threw me off, but then I just took the plunge and read the source, after which things were a breeze. 🙂