Today we arrived at the third installment about best practices in Java. This time I will be talking about the well known, but often sinned against practice of eating up exceptions. Next to that we will be looking at some cases where mixing JSTL and JSF might not be the best way to go.

Eating up exceptions; continuing with invalid data

Handling exceptions in Java (and to be fair, in most other languages) is a rather difficult topic. One can try to handle the exception directly (e.g. trying a fall back server after a TimeOutException is thrown when accessing the primary server), but this is certainly not always possible. Confronted with their inability to handle an exception, some programmers choose to just ignore the exception and carry on as if nothing has ever happened. This practice is also known as “eating the exception”. In code it looks like this:

The thing is that something bad -has- happened and pretending it hasn’t doesn’t magically make it go away. Compare this with ignoring that little red light which tells you you’re almost out of gas. You can drive on pretending all is fine, but inevitably you’ll find yourself stranded at some desolate place, wishing you hadn’t been so careless.

A major problem with eating up exceptions is that most likely your application is in an invalid state afterwards. Continuing on only drags your problems along until ultimately something crashes anyway.

Such a crash however may occur at a completely different location and at a much later moment, making if very difficult to find out the true cause.

Besides a downright crash, another risk you’ll run is that invalid data might be persisted somewhere or that operations will be carried out with missing data. Suppose you’re the programmer that ate the exception that occurred when a user registered itself and your code allowed an order to take place without having anyone to bill. Chances are high more than a few people won’t be too happy with you.

The least, the very least you can do is log the exception when it happens so you’ll have at least some clue where to look if ‘mysterious’ things happen. Better yet, throw the exception upwards if you can’t handle it. Ultimately it might reach the user in some form (e.g. through an error page). It’s true, users don’t like error messages, but they like a system that tells them something went well when in fact it didn’t even less.

Mixing JSTL and JSF for common cases

For starters, don’t get me wrong. Using both JSTL and JSF on the same page is not a bad practice by itself. It used to be unsupported in the separate JSF 1.1 release, but starting from the version that came with Java EE 5 (JSF 1.2) mixing JSTL and JSF is explicitly supported.

The fact that you can mix them however tends to lure some programmers into using JSTL in ways for which there are better or cleaner JSF alternatives. Two common cases where this happens is for conditional rendering using the c:if tag and building a table from a collection using the c:foreach tag.

Use of the c:if tag in JSF is rarely required as most components make use of a renderedproperty. If you need to render multiple components conditionally, just wrap them in a h:panelGroup and set the rendered property on that one.

Likewise, use of the c:foreach tag just to build a table can often easily be replaced by the h:dataTable tag. Practically, the results are comparable. Both iterate over a List, array, etc and in effect execute their body’s content. In code they look similar too:

However, not only does an h:dataTable based component look more at place in a JSF page, there are also important technical differences. The JSTL taghandlers aren’t components. They serve to build the component tree and subsequently disappear. For some programmatic processing of the component tree this may pose a problem. Another technical difference is that an iterating JSF component doesn’t in fact create an individual component for each iteration. Instead, its children are typically created only once and are evaluated each iteration. This is in stark contrast with the JSTL foreach tag. Without being a ‘managing’ parent and without explicit knowledge about JSF, the c:foreach can do nothing more than add a new component instance to the tree for each iteration. This may or may not be the end of the world, but you should be aware of this difference.

One advantage of the c:foreach approach may be the fact that it allows you to render markup without using the HTML table element. This is often considered an advantage when creating renderings that are in fact not tables. The limited set of standard components in JSF don’t provide support for this, but the 3rd party library Tomahawk contains a t:dataList component that can be used for exactly this.

A third variant, which by itself isn’t technically bad but just looks out of place, is the usage of JSTL for rendering a table in a page that otherwise consists of JSF components:

So the moral of the story is. Yes, you can mix JSTL and JSF (1.2), but don’t do it if there are JSF specific solutions available. Only use JSTL if you’re absolutely sure that the rendering you wish to create really needs it and be aware of any technical consequences.

This entry was posted
on Sunday, August 26th, 2007 at 11:35 pm and is filed under Java.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.