kdb+/q - Try Catch

Programming languages typically have a try-catch mechanism for dealing with exceptions. The try block contains the code you want to execute and the catch block contains the code that will be executed if an error occurs in the try block.

Here is an example of a simple try-catch block in Java, which attempts to parse a string into an int and returns -1 if there is an error.

try {
    return Integer.parseInt(x);
} catch (NumberFormatException e) {
    e.printStackTrace();
    return -1;
}

In this post, I will describe the try-catch equivalent for exception handling in the q programming language.

.Q.trp[f;x;g] - for unary functions

For unary functions, you can use .Q.trp (Extend Trap), which takes three arguments:

1. f - a unary function to execute
2. x - the argument of f
3. g - a function to execute if f fails. This function is called with two arguments, the error string x and the backtrace object y

For example:

// Define a function which casts a string to int
parseInt:{[x] "I"$x}

// Define an error function which prints the stack trace and returns -1
// Note: .Q.sbt formats the backtrace object and 2@ prints to stderr
g:{[x;y] 2@"Error: ",x,"\nBacktrace:\n",.Q.sbt y;-1i}

// Try calling the function (wrapped by .Q.trp) with a valid argument
.Q.trp[parseInt;"123";g]
123i

// Try calling the function (wrapped by .Q.trp) with an invalid argument
// The error function is called and the stack trace is printed
.Q.trp[parseInt;`hello;g]
Error: type
Backtrace:
  [2]  parseInt:{[x] "I"$x}
                        ^
  [1]  (.Q.trp)

  [0]  .Q.trp[parseInt;`hello;g]
       ^
-1i

Note: An alternative is to use Trap At which has syntax @[f;x;e] but you won't get the backtrace, so it's better to use .Q.trp.

.[f;args;e] - for n-ary functions

.Q.trp only works for unary functions. For functions with more than one argument, you need to use Trap which has the syntax .[f;args;e]. The error function e does not take any arguments, which means no backtrace available. For example:

// Define a ternary function that sums its arguments
add:{[x;y;z] x+y+z}

.[add;1 2 3;{2@"Failed to perform add";-1}]
6

.[add;(1;2;`foo);{2@"Failed to perform add\n";-1}]
Failed to perform add
-1

Stackless Exceptions for Improved Performance

One of the reasons for standard exceptions being slow is that they have to fill in the execution stack trace for the current thread. Although, this is useful for debugging, in most cases you don't really care about the stack trace. What you care about is that an exception of a certain type was thrown and what the error message was. For example, a java.io.FileNotFoundException was thrown with message config.xml (The system cannot find the file specified)".

Stackless Exceptions are exceptions without any associated stack information. They are faster to create than normal exceptions because they don't record information about the current state of the stack frames for the current thread.

The class below is an example of a stackless exception. The fillInStackTrace method has been overridden so that it doesn't do anything and simply returns the current instance.

/**
 * An exception which does not fill in a stack trace
 * for performance reasons.
 */
@SuppressWarnings("serial")
public class StacklessException extends Exception {

    /**
     * Constructs a new stackless exception
     * with the specified detail message.
     *
     * @param message the detail message.
     * @see java.lang.Exception#Exception(String)
     */
    public StacklessException(String message) {
        super(message);
    }

    /**
     * Does not fill in the stack trace for this exception
     * for performance reasons.
     *
     * @return this instance
     * @see java.lang.Throwable#fillInStackTrace()
     */
    @Override
    public Throwable fillInStackTrace() {
        return this;
    }
}

I measured performance by comparing the time taken to create a million StacklessException and Exception objects. I found that the creation of stackless exceptions is nearly 40 times faster than normal exceptions.

You can then create more specific exception types which subclass StacklessException. For example:

public class PersonNotFoundException extends StacklessException {
    public PersonNotFoundException(String message) {
        super(message);
    }
}

As an aside, note that the JVM omits stack traces if an exception is thrown very frequently. This optimisation is enabled by default and can be disabled using the JVM option -XX:-OmitStackTraceInFastThrow.

Automatically Retry Failed Jobs in Quartz

How do you handle job failures in Quartz? There are a few things you can do:

• Do nothing. Let the job fail and log the error.
• Retry continuously until the job succeeds.
• Retry n times and then disable the job.

In this post, I will describe how you can configure your jobs to be retried on failure.

Retrying continuously until success:
If you want to keep trying over and over again until the job succeeds, all you have to do is throw a JobExecutionException with a flag to tell the scheduler to fire it again when it fails. The following code shows how:

class MyJob implements Job {

  public MyJob() {
  }

  public void execute(JobExecutionContext context)
                  throws JobExecutionException {
    try{
        //do something
    }
    catch(Exception e){

        Thread.sleep(10000); //sleep for 10 secs

        JobExecutionException e2 = new JobExecutionException(e);
        //fire it again
        e2.refireImmediately();
        throw e2;
    }
  }
}

Retrying n times:
It gets a bit more complicated if you want to retry a certain number of times only. You have to use a StatefulJob and hold a retryCounter in its JobDataMap, which you increment if the job fails. If the counter exceeds the maximum number of retries, then you can disable the job if you wish.

class MyJob implements StatefulJob {

  public MyJob() {
  }

  public void execute(JobExecutionContext context)
                                 throws JobExecutionException {
    JobDataMap dataMap = context.getJobDetail().getJobDataMap();
    int count = dataMap.getIntValue("count");

    // allow 5 retries
    if(count >= 5){
        JobExecutionException e = new JobExecutionException("Retries exceeded");
        //unschedule it so that it doesn't run again
        e.setUnscheduleAllTriggers(true);
        throw e;
    }


    try{
        //do something

        //reset counter back to 0
        dataMap.putAsString("count", 0);
    }
    catch(Exception e){
        count++;
        dataMap.putAsString("count", count);
        JobExecutionException e2 = new JobExecutionException(e);

        Thread.sleep(10000); //sleep for 10 secs

        //fire it again
        e2.refireImmediately();
        throw e2;
    }
  }
}

Throw a checked exception from a method without declaring it

When you try to throw a checked exeption from a method in Java, the compiler will force you to either catch it or declare it to be thrown in the method declaration. For example, the following method fails to compile:

public void go(){
    throw new IOException();
}

The compiler says:

Dummy.java:15: unreported exception java.io.IOException;
must be caught or declared to be thrown
    throw new IOException();
    ^
1 error

However, if you declare it to be thrown in the method declaration, like this:

public void go() throws IOException{
    throw new IOException();
}

then it compiles successfully.

But is it possible to throw a checked exception WITHOUT declaring it to be thrown? You could wrap it in a RuntimeException (for example, new RuntimeException(new IOException()), but then you lose the ability to catch the checked exception in the caller method, because you have changed the type of the exception.

There is another trick you can use. I first noticed this being done in the JDK's java.lang.Class#newInstance0 method:

private T newInstance0()
    throws InstantiationException, IllegalAccessException
{
    ...
    // Run constructor
    try {
        return tmpConstructor.newInstance((Object[])null);
    } catch (InvocationTargetException e) {
        Unsafe.getUnsafe().throwException(e.getTargetException());
        // Not reached
        return null;
    }
    ...
}

As shown above, the method throws an InvocationTargetException but only declares the exceptions InstantiationException and IllegalAccessException to be thrown! The Sun utility class sun.misc.Unsafe is being used to throw a checked exception without declaring it. We could use the same approach, but unfortunately our code throws a security exception when we try to use it: java.lang.SecurityException: Unsafe. However, we can bypass this by using reflection to get hold of the unsafe variable directly, as shown below:

public void go() {
  getUnsafe().throwException(new IOException());
}

private Unsafe getUnsafe() {
  try {
    Field field = Unsafe.class.getDeclaredField("theUnsafe");
    field.setAccessible(true);
    return (Unsafe) field.get(null);
  } catch (Exception e) {
    throw new RuntimeException(e);
  }
}

So, why did the JDK developers do it this way? I don't know, but I'm sure they had a good reason. Although this is a neat trick to impress your friends, I wouldn't recommend using it. This is non-standard, undocumented, Sun-specific code which could change in future releases and may not be compatible with all JVMs. It also makes code harder to understand for others and violates the POLA.

Further Reading:
Avoiding Checked Exceptions [O'Reilly]