Search code examples
axaptadynamics-ax-2012x++

Exception reason/message. Am I reinventing the wheel here?

I want some kind of mechanism to have more information about a caught exception. (Specifically exceptions I throw myself to abort transactions) I've looked around and pretty much the only thing I could find was "Use the info log". This to me does not seem like a good idea. For one it is cumbersome to access and find the last message. And it is limited in size so at some point the new messages won't even show up.

So my idea is the following: Create a class NuException and pass an instance of that through all methods store an instance in the class where the work methods are located. When I need to throw an exception I call a method on it similar to Global::error() but this one takes an identifier and a message.

Once I reach my catch block I can access those from my object the class that contains the work methods similarly to how CLRExceptions work.

class NuException
{
  "public" str identifier;
  "public" str message;

  public Exception error(str _id, str _msg)
  {
    //set fields
    return Exception::Error;
  }
}

class Worker
{
  "public" NuException exception;

  void foo()
  {
    throw this.exception.error("Foo", "Record Foo already exists");
  }

  void bar()
  {
    this.foo();
  }
}

void Job()
{
  Worker w = new Worker();
  try
  {
    w.bar(ex);
  }
  catch (Exception::Error)
  {
    info(w.exception().message());
  }
}

It works but isn't there a better way? Surely someone must have come up with a solution to work around this shortcoming in AX?

Solution

  • Short answer: yes.

    While your "brilliant" scheme "works", it gets boring pretty fast, as you now must transport your NuException object deep down 20 level from the listener (job) to the thrower (foo). Your bar method and other middle men has no interest or knowledge about your exception scheme but must pass it on anyway.
    This is no longer the case after the update.

    There are several ways to go.

    1. Use an observer pattern like the Event broker or in AX 2012 and newer use delegates.

    2. Stick to the infolog system and you use an InfoAction class to peggy bag your information to be used later. It can be used to display a stack trace or other interesting information.

    3. Use a dedicated table for logging.

    The third way may seem impractical, as any errors will undo the insert in the log. This is the default behavior but can be circumvented.

    MyLogTable log;
Connection con = new UserConnection();
con.ttsBegin();
log.setConnection(con);
... // Set your fields
log.insert();
con.ttsCommit();

    Your way to go depends on circumstances you do not mention.