One of the few things that lack seriously, IMO, in C# is the power of Java checked exceptions. In Java world? things happen weirdly. Maybe it is a result of crowd intelligence and a bad side effect of open source. Often, people in J2EE world tend to believe the opposite. Anyway you see the effect in most preferred frameworks (such as today’s popular ORMs and Containers) of wrapping checked Java exceptions and rethrowing them as runtime ones.

I guess offering runtime exceptions together with compile time ones did a hole in the Java type system, but this hole was left to discipline, in a way of giving the tools and letting smart enterprise programmers decide for the right tool for the job. Things turned to happen differently in the enterprise world.  Programmers abused of this freedom of choice and mainstream frameworks designers decided to dismiss and bury one of the most interesting features of the Java type system.

Why do I like Java checked exceptions? Well simply because it saves me from surprises. And I tend not to like surprises much!

The funny thing is that, in my experience, it is mostly architects that dismiss Java checked exceptions whereas Compile time exceptions are a very good asset for cleaner and bug free architecture.

I just take a look at a “standard” DAO method that gets an entity

Customer getCustomer(CustomerId id);

This method lies! what if there is no connection? what if the Id is incorrect? The signature of the methods gives quite a promise that under all circumstances it will returns a Customer. Now for any architecture this is bad. It used to be better before some popular frameworks decided to completely omit it! Before? well I used to control my architecture better!

Before these “good practices” become mainstream, imposed in mainstream frameworks, It used to be often more predictable the return type a method has. For my example, the signature would tell me that the method will either return a customer OR throws a “Dao Exception”.

Customer getCustomer(CustomerId id) throws DaoException;

No surprise. Now when I use this method, I will certainly need to handle the case when the method will return something else than a Customer. Now of course, a Java “enterprise developer” could do one of to things:

1- Out of laziness or incompetence, keep rethrowing data access exceptions up until you’ll have to deal with it up in the GUI logic (where handling an infrastructure error does not often belong)

This often sounds for me the main argument for dismissing Java Compile Time Exceptions claiming that it is a “code boilerplate”. The thing is that you’ll have to deal with these exceptions once even when you turn them into runtime. The fact of wrapping them into runtime does not eliminate them (even if I wish it did). But having them as compile time will make easy to spot where a “bad” developer did not handle the exception correctly simply by following the signature and type system. Then the solution will be to wrap them into more business friendly, context meaningful Compile Time Exceptions that need to be handled. This way the contract communicated better the result of executing a piece of logic.

This turns to be as useful for “void” return type methods. With Compile Time Exception a method can simply communicate the fact that it will either return “void” or will throw an exception to be handled.

2- Out of laziness or incompetence, frustrated developers will start “catch”ing checked exception without rethrowing them.

This one is a result of the hole in the type system that is left intentionally to leave some place for flexibility relying on discipline. Nevertheless, and before the big favor of generous frameworks I mentioned earlier, this turned out to be an easy problem to spot. Most IDEs and code analyses tools can find easily empty catch clauses and warn me about them.

I often get surprised of the limited use of Java language wealth in enterprise J2EE applications!

Good thing: C# and .Net are introducing checked exceptions together with other DbC stuff (like non null objects) in the next release. Sad thing: Java has Compile Time Exceptions since version 1, open source chose to unvalue them!

Having worked with several Object-Relational mapping frameworks in the last few years, I got to a point where I couldn’t justify their complexity in my project. We often talk about the mismatch between the database and the object worlds, and that is where ORMs are often stated and referenced for “bridging the gap”!

Well I prefer to call it lifting the gap, or highering the gap, to have it now between DAOs and the rest of the code than having it between database and code.But I wouldn’t call this in any way reducing the gap.

First thing to mention here, is that data structures are not evil. We often deal with XML data structure but we absolutely refuse to deal with relational data structures. The problem might be related to time, XML came with a whole arsenal of managed APIs that represent its model in a way that makes it more comfortable for you to manipulate these documents. All together with transformation APIs that made it a lot easier to fill your object model out of an XML. Relational data structure on the other hand did not have the luxury of standard APIs and representation models in mainstream languages, and that made dealing with a database request result so arbitrary (Datasets existed in .Net but they have been cursed heavily and has been forced out of the cool toolbox, do not know yet why!) . 

In some way, I guess that the “mismatch” between Relational data structures and objects exists much similarly between XML and objects, however we didn’t think for so long of a doing a mapping between XML and object OXM? (no we are starting to do so, writing some XML to map XML to objects!).

With the experience I had with mapping technologies, I can say that they do not solve the problem for me. They merely add yet another useless level of abstraction where your domain types look nothing like relational data structures, but yet nothing like your target domain model! They have gone a half way, and now its your turn to poison your application with a lot of absurd ORM code trying to stretch this bridge to reduce the gap…

Geeks love talking about intrusivty of an ORMs and compare level of intrusivty in different terms. Intrusivty is much more than the lack of an interface or methods to implement in your domain objects. I guess I am ok to deal with that kind of intrusivity. However all ORMs I tried do not give me the opportunity to express my domain model in the way I would like to. I have to deal with notions of Lazy Loading, Attached/Detached entities, Entity sets, ids, back fields and a lot of other things that I don’t want to appear in my model and that make the resulting code so ugly and complex that I don’t wish to visit soon.

As Bob Martin said before, we are missing the opportunity to do oop, I would enforce and say we are missing the opportunity to model at all. And I guess we have gone too far with ORMs and it is time to go back to the basics, in the same way we have done after the EJB great abstraction.

It is very contradictory, while we are so excited about DSLs and the goodness they can potentially bring to enterprise development that results in a declarative semanticful style of programming, we can’t help but to engage all of our means in trying to bury SQL (and effective, semanticful, declarative powerful domain specific language) behind a dumb API to “abstract database access”! I guess we got to chose one strategy, either we keep SQL and we  keep marketing DSLs or we hope for a new advanced GPL compiler that will hide all of this in the same way modern languages did with garbage collection, concurrency and synchronization.

Since I am not yet a compiler writer, and I aint got around an effective way of integrating database in mainstream languages (there is actually a very productive in memory database on Haskell that worth trying), I decide to keep the DSL, and to work with them without the need to hide them, but rather to get a better tooling to help converting between difference data structures.

I guess you’ve guessed it by now. For me LinQ is the mid-term solution for the data structure mismatch. No not LinQ to sql, nor Ado.Net entities (they are helpful and we might use them but lets focus on the solution). LinQ is a very productive tool that halps effectively transform anything to anything in few lines of code. I mean that I can still use powerful SQL to get data effeciently and then convert them with one line of LinQ into the destination data structure. No abstraction leak, less complexity: Use the right tool where it applies.

So what I would actually do is to use a framework that will execute my SQL or SQL like query on the database and get me the records in much the same way they are in the database,Much in the same way Active Record gets you records as they are in the database. No useless efforts from the framework to bend the data to make it look untruthfully like the destination model.  I guess I know better my domain model, and with this better tooling I can get it done with no problem.