Enhance Exceptions with Context

Don't you wish sometimes that Java had the feature for exceptions to automatically capture the values of the variables in the context that were present when an exception occurs? Well I guess we just have to do it manually. Let's see what it would look like:

public class SomeClass {
public void someMethod(String x) {
  try {
    int pos = x.indexOf("abc");
    String y = x.susstring(pos);
  } catch (RuntimeException e) {
    throw new RuntimeException(
      "there was a problem here, with param x="
        + x, e);
  }
}
}

Ok, now whenever someone calls someMethod("noa-b-c"); they will get a friendly message in the exception telling them what the value of x was during the invocation. That wasn't too bad, but what if the method had 3 parameters? What if you didn't have the try block around the whole body and it still threw an exception?

There must be a better way? I don't want to always tell the computer how to do things, how come I can't just say what I want? I want to tell Java that when an exception happens in my method, it should capture the context and chain the original exception. I will just use an annotation to tell Java to do this for me.

public class SomeClass {
@ThrowsContext
public void someMethod(String x) {
  int pos = x.indexOf("abc");
  String y = x.substring(pos);
}
}

There, that is better! Um, wait, how is that going to work? Now I am going to have to make something that will process that annotation and put the try catch there and include the parameter values. I could run my code in some sort of container that I can proxy the object of SomeClass and in the proxy I can add this new feature, then I need to make sure that all my clients to this method go through the proxy, then oops, I need to use CGLIB because I didn't use an interface, man, that is goign to all be easy.

There must be a better way! AspectJ is still Java, let's see if that wil work. We can create a pointcut for methods that have the @ThrowsContext annotation, and after the method throws an exception, we will chain it with our exception with a message of the context and chain teh original exception.

public aspect ExceptionContext {
 pointcut ctx(ThrowsContext t, Object th) :
   execution(@ThrowsContext * *..*(..)) &&
   @annotation(t) &&
   this(th);

 after(ThrowsContext t, Object th)
     throwing(RuntimeException e) : ctx(t, th) {
   Object[] args = thisJoinPoint.getArgs();
   throw new RuntimeException("parameters: " +
     Arrays.toString(args) + "\nthis=" +th, e);
 }
}

That is pretty to the point, it says what I want to do which makes programming more productive and fun. Maybe you don't want the context to leak out of your components, but you need this information to support debugging durign development, you can use LTW Load Time Weaving supported by AspectJ to only add this aspect behavior during deployments that you decide should have it.

Next time we will enhance the context and provide options to which context to include.


And here is the annotation:

@Retention(value=RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ThrowsContext {
}

How Important is Symmetry in JPA?

When you are designing a domain model using JPA or hibernate or another declarative approach to ORM, you must decide the cascade rules for creating and deletign objects that are related to each other. When you have a one-to-many relationship between two objects, when an object is persisted, you need to decide if the related object should be automatically persisted as well, or should you have to persist each object?
To me it seems that this must be made symmetrical, that is if you cascade create, then you should cascade delete as well. Any other rule than this makes your system more complicated. Intuition should be available to one trying to understand your domain model, and symmetry is a part of nature, so it will be intuitive to expect a consistent behavior. If you are using JPA, the cascade rules will be in the code so you will see the rule with the code so it will be evident of your choice. In the case that you are using Hibernate from an XML configuration file that is not visible at the same time as the source code, then you will have to remember the cascade rules, minimizing the burden of memorizing too many things can help in comprehending your model, a consistent rule of always cascade create with delete will eliminate this from your efforts.
In a more encapsulated direct approach, I recommend that a new annotation of @Aggregation be created that has this behavior as it's meaning, it is simple and precise as to the intent. AspectJ can be used to create this annotation, and with JPA annotations as the ORM approach, the needed annotations can be injected behind the scenes. This seems like a nice clean use of AOP to help in using of JPA.

Aspect Query Language

An aspect oriented database should support an aspect oriented query language. What would the aspect paradigm do to influence other query languages? There is SQL, JDOQL, EJBQL, OQL, and others. AQL or "Aspect Query Language" would be a query language that supports queries against an aspect oriented database. There are persistent aspects, and persistent data that has been annotated by aspect introduced metadata. An aspect oriented database is a regular database that contains metadata or out of band data integrated with objects. Sure anydatabase can create metadata tables and join it to another table. So what is special about the aspect metadata? In part is a matter of representation, that is there will be keywords distinguishing the aspect data from the object data. The other side of the power of aspect data management is the implicit introduction of information based on contexts of the usage of objects in relationships.