I finally bit the bullet and did some major refactoring to how sys::Err works that I've been procrastinating for several months. Up until this point Err has actually subclassed from RuntimeException rather than Obj which obviously doesn't work when you actually start using Err in Fan code. Now Err subclasses from Obj, and each Err has a supplemental Err$Val class which extends from RuntimeException. Err stores its Java value in a a field called "val" just like Int, Real, and Str:

class Err extends Obj
{
  Err(Err.Val val) { this.val = val;  val.err = this; }

  public static class Val extends RuntimeException
  {
    public String toString() { return err.toString(); }
    public Err err() { return err; }
    Err err;
  }

  public final Val val;
}

class NullErr extends Err
{
  public NullErr(NullErr.Val val) { super(val); }
  public NullErr() { super(new NullErr.Val()); }
  public static class Val extends Err.Val {}
}

So you can see that subclasses of Err have their supplemental Err.Val classes subclassing their respective types to build up a parallel class hierarchy in both the Fan and Java type systems. This will become important when we implement typed catch blocks. The exception classes in Sys are hand coded as above along with their suite of make and make$ methods.

For exceptions derived from Err in Fan code, the bytecode emitter now has more work to do because it has to generate the supplemental Err.Val type as well as handle the two special constructors (one no arg and one with a Err.Val parameter like the NullErr example above). I handled this case with two new classes in my fanx.emit package: FErrEmit and FErrValEmit.

Throwing an exception in Java code now looks like this with a trailing access to the val attribute:

throw Err.make("not good").val

This same bit of code is also generated when implementing the Throw opcode.

John it looks like you took the same approach as me for Err and will need to implement a similar solution to get ErrTest to pass.