Tag Archives: Development

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

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!

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

Crystal Clear – by Alistair Cockburn

Crystal Clear is the smallest of a series of methodologies for software development, all created by Alistair Cockburn. It is smallest in the sense of the project size it addresses (up to eight developers) and in the number of things it prescribes. Other Methodologies, deriving their names from the colors of crystal, are increasingly heavier. They all share the same “DNA” though, which is “expressed” differently with increasing project size and criticality, the latter meaning the higher cost in terms of money or at the extreme human life.

The book in itself has an interesting setup where each chapter addresses an aspect of Crystal Clear in a different format, tone and style. The purpose of this setup is to appeal to a large audience where each reader can find at least one chapter that conveys the essence of Crystal Clear to her clearly. The most peculiar chapter is probably the one where an ignorant Alistair queries a fictive Crystal character over a series of letters about the inner workings of a successful software development team; thus mimicking a Socratic dialogue. I am not sure this stunt works in practice, but at least true to the intent some chapters work better for me than others… All chapters are, however, still written in an easy and personal prose.

Continue reading

Beyond Software Architecture – Creating and Sustaining Winning Solutions – by Luke Hohmann

In Beyond Software Architecture, Luke Hohmann addresses all things paramount to software product development that are usually not covered in books on software development. These things include licensing, software protection, branding, marketing and business plans and how they relate to the technical architecture and more. Every developer or architect that has been around a few projects probably will probably recognize the importance of some, if not all of these areas, in relation to creating and sustaining a winning solution.

The first and probably most important topic covered is the relation between the business model and the technical architecture. It is really an understatement to claim that the chosen business model has a serious and real impact on the technical architecture – it should be self evident that there the architecture will look quite different in an ASP scenario and a single user desktop application… Less self evident is the relation between the business plan and the technical architecture. What business segments are being targeted and in which order really does bear on the architecture. Each business segment will have its particular needs to be addressed as features in the software solution. The order is important since it will help spell out the technical roadmap for future releases.

The book covers a large number of topics and gives advice on a number of specific issues, too many to cover here. I have chosen but a few that have stuck after finishing the book.

Continue reading