Exception handling using enumerations in Java (II)

In the first part of this blog post I discussed how Java Enumerations can be conveniently used as

  1. Fault codes in exceptions; and
  2. Provide formatted and localized error messages

The major drawback with the approach is that the fault codes make exception handling more complicated for cases when the same logic should be applied to different enumeration types.

This part of the blog post discusses a possible extension of Java Syntax for better exception handling when using enumeration fault codes.

First we need a way to distinguish the exceptions that support fault code enumerations from those that do not. We also need to indicate what type of fault code is supported by the exception. We therefore introduce a a new Fault interface from which all fault code exceptions must inherit:

If we for a given application assume an ApplicationFault Exception class defined as

… we can then specify the fault code as constant values for the exception, i.e. something like

This new syntax should be interpreted as

  • Handle all ApplicationExceptions for fault codes Code.A1 and A2 and
    IOExceptions in the same way
  • Handle ApplicationExceptions for Code.A3 faults separately
  • Allow all ApplicationExceptions for Code.A4 faults to propagate up the
    call chain

(The Code enumeration type can be deduced from the ApplicationException.)

In addition, compile time errors would occur if

  • Non-existing or the wrong enumeration fault codes for the class are referenced
  • ApplicationFault does not implement Fault
  • ApplicationFault is a checked exception and not all fault codes are caught

We could even take it one step further if Java would allow generic type parameters for Exception classes. (Exceptions in Java do not support generic type parameters as there is no evident use for them, but if we introduce fault codes they would start making sense.)

Let us assume that the JDK defines a generic RuntimeFault:

We would then only need to define our fault codes in an enumeration (Localized or not), throw them as follows:

… and catch them like so

The main motivation for allowing generics in this way would be to have fewer exceptions. Instead of defining a new exception for each application or module with its own set of fault codes we would only define the fault codes and in most or all cases use the default RutimeFault exception class.

While this might be tempting we need to answer a number of questions introduced by the additional complication of allowing generics in exceptons:

  • Would other exceptions besides RuntimeFault be allowed to be generic in the
    same way?
  • Would the generic type parameters be limited to enums? If not, what would that
  • Should we perhaps allowing catching the interface Fault as well? What class
    object would be assumed in the catch clause?

There are probably limitations related to type erasure and how the catch clause is implemented in Java that would answer these and other questions. Unfortunately I lack the insight to provide a good answer on the feasibility of any of the extensions suggested above.

In a blog post from last year the author proposes changes to Java 9 that pretty much attempts to solve the same problems as discussed in this post, but instead of using enum codes the solution is based on Strings. He actually goes as far as making a forked JDK to test the the new feature!

To catch the codes the author introduces a new syntax:

The CodedException class is required to be part of the catch clause for the codes to be caught.

To me the syntax is a bit clumsy as the CodedException is not kept together with the codes and using String constants is error prone. How do we known the fault code is ever thrown? With enumerations you get type safety and all codes has at least to be defined somewhere.

Last defining a single code is a bit more verbose, compare:

… as opposed to

Granted, there is a little bit of overhead not shown where we store the MessageFormat in the enumeration but this is quickly regained when there are more than a few codes.

Exception handling using enumerations in Java (I)

When I first read about Swift I quite liked its error handling.

In Java checked exceptions have gotten quite a bad rep but instead of throwing out the baby with the bathwater and getting rid of checked exceptions altogether, the way they do it in Swift seems to strike a good balance.

The thing that caught my eye however, was the use of enumerations instead of exception classes.
Continue reading

What is Strategy?

As an assignment in the Strategy and Marketing course of my ongoing MBA studies we were required to give our personal view of what strategy is and I thought I should publish the result here. Part of the reading for the assignment included five articles from Harvard Business Review, three by Michel Porter and two by Kathleen Eisenhardt.

The three articles by Porter takes a high level perspective, defining strategy in terms of the nation state, the industry as a whole and strategy at the highest level of the enterprise. Essentially this is a top-down perspective, or perhaps one could call it outside-in. For Porter strategy is about making conscious trade-offs (what not to do), supported by a unique set of activities that reinforce each other and are difficult to reproduce, all in all creating a unique strategic position giving a sustainable competitive advantage (What is Strategy, p 70).

In the two articles by Eisenhardt et al strategy is something emergent, arising from the pattern of activities (patching and the application of simple rules). It is more about the internal strategy process than finding a strategic position. Essentially this is more of a bottoms-up perspective on strategy, or perhaps one could say inside-out.

Porter and Eisenhardt also differ in the time scale of strategy. Strategy in the eyes of Porter is long term; if a strategy does not lead to a sustainable advantage with a high performance outcome, it is not strategy or at least not successful strategy. As a counter point, the two articles by Eisenhardt et al discuss strategy with a shorter horizon (“internet time”).

Continue reading

Diaspora Seeds

Recently a couple of New York college students made a stir when they announced that they would write an open source and distributed social network server as an alternative to Facebook. This is really in the true spirit of the internet, where everyone can set up his or her own server and have them commicate, compare e.g. how email works. Incidentally, this is the way Instant Messaging should work but only SIP and Jabber (used by e.g. Google Talk) actually implement. Evidently they have raised about $170 000 in three weeks using Kickstarter, their initial target was $10 000.

I sympathize 100% with their stated goals and will make sure I set up a Diaspora Seed once they make their first release.

More information on the Diaspora blog.

Toyota and Waterfall methdology for developing software

As you may know Agile software development is inspired by the principles of Lean Manufacturing which in turn is derived from the Toyota Production System (TPS). One Agile methodology, Lean Software Development even borrows the name Lean to make the connection explicit. Since the principles in Lean and TPS have much in common with how Japanese always have approached manufacturing and that TPS supposedly permeates the whole of Toyota, it comes as a real surprise that Toyota uses a waterfall process for software development!

REST for Scott

At the thanksgiving dinner of a friend from work I tried to explain REST-ful applications – and I think I failed miserably. Even though there are plenty of good introductions out there I felt I needed to organize my thoughts a bit. Having some spare time on the train on the way home I made a second, more structured attempt in the form of this blog post.

Imagine you are a web developer and is asked by a friend with a travel agency to help out create a web site for his company. Among the services on the site is a small web application for searching for hotels recommended by the agency. These hotels have been carefully vetted for the agency’s customer segment and useful hotel information is stored in a database.

Continue reading

SOA is Dead (but the corpse is still kicking)

In a famous post from January this year (which I missed) Ann Thomas Manes declares SOA dead. She is a Reasearch Director within the Burton Group, has worked with SOA in the Burton Group and elsewhere, and is a co-author of the WS-* specifications.

The post has sparked fierce defense from vendors like Oracle. During the half day SOA Architect forum in Geneva this Tuesday, Oracle spent the first seminar repeating that “SOA is not dead” like a mantra, I guess in order to reinforce the message. It seemed to be one of the mayor points they wanted to get across.

Continue reading

Universal Assembly Cache – Dependency Management for Mono and Microsoft.NET

In the Java world there are several ways of handling dependencies between project components in a shared development environment. Maven is a generic build tool that creates a standardized way of creating, building and publishing component artifacts. Dependencies between the different components are declared in a Maven build file and Maven automatically downloads the dependencies and all transient dependencies recursively from local or public repositories. Repositories can be local to a particular developer, department or enterprise; or they can be public, available to the development community at large. Ivy is another utility which focus solely on dependency management. It is positioned as the lean and simple alternative to Maven which focus only on the dependency aspects and that integrates well with Ant (the generic java build tool).

For .NET based solutions there does not seem to be neither a Maven nor Ivy style dependency management system for development. This article outlines a solution to dependency management in the .NET world that has been inspired by the Maven and Ivy.

Continue reading