Change in code unit error handling with 2013 R2?

This question is answered

We have several code units that connect to managed .NET dlls. Inside those code units, we throw errors and expect .NET to catch them. This worked in 2009 and 2013, but broke with 2013 R2.

Previous behavior:

Code unit would hit a condition, throw an exception to .NET and continue.

Current behavior:

Code unit hits the condition, throws the exception, but the NAS shuts down as if it were a fatal exception. our .NET dll catches it, but gets disconnected from the server and our application halts.

Code Unit Sample:

ERROR('Add the ' + TableName + ' table to the Validation Rules table.');

Did the behavior of this ERROR keyword change between 2013 and 2013 R2? Is there a better way to do what we're trying to do without killing the NAS service?


Verified Answer
  • So, after weeks of research, banging my head on rocks, walking around in circles counter clockwise, I finally figured it out.

    Short answer is that NAV 2013 R2 requires that you handle exceptions. ERROR exceptions can be thrown, but they have to be 'caught'. AND the referenced .NET code cannot throw unhandled exceptions. Any unhandled exceptions will halt the NAS.

    In the CAL code, we had to move a bunch of code around, pushing it down an additional layer. To correctly catch the exception, the code executes in the OnRun method of our new units. It's OK to throw an exception here as long as the calling method catches that error; like this:

    IF NOT SomeCodeUnit.RUN THEN BEGIN

        SomeText := GETLASTERRORTEXT();

        CLEARLASTERROR();

        HandThisErrorToDotNet(SomeText);

    END;

    Where SomeCodeUnit can throw ERROR until the cows come home. 

    Hope this helps future NAVrs. 

All Replies
  • hi

    no, only GETLASTERRORTEXT function was changed on R2.

    Just a suggestion

    you might try to use the solutions presented by Vjeko Babic at Nav Tech Days a few days ago to call dll using. NET interoperability, which manage the try \ catch functionalities, take a look.

    . NET Interoperability Black Belt Session

    vjeko.com/.../nav-techdays-2013-in-antwerp-wrap-up

    Download the PowerPoint slide deck here: vjeko.com

    Download the NAV objects as FOB (for 2013 R2) here: vjeko.com

    Download the NAV objects as TXT here: vjeko.com

    Download the Visual Studio solution for all sessions here: vjeko.com

    ------------------

    Roberto Stefanetti

  • Thanks for the code samples. I went through them and we're doing basically the same thing. One thing I noticed is that 2013 R2 logs errors to the event viewer when I hit this code. The stack trace makes it look like NAV is trying to display a window when ERROR is executed.

    We submitted a ticket to Microsoft about this and they said it's probably a defect on their end. If I find anything out, I'll post it here.

    thx

  • SH_SCRIBE any word from Microsoft on whether this is a bug or an intended change? I am experiencing the exact same behaviour.

  • Short answer is, No. They said there haven't been changes in ERROR. But, in the NAS configuration, there's a 'number of restarts' that's preset to 3. The tech I'm working with hinted that whatever code reads this might be new.

    Here's what I think is happening:

    When C/AL hits an ERROR, it restarts the NAS. It seems that it always has. But there's new code around how many times the NAS will attempt a restart before it fatally shuts down. THIS seems to be new in R2. In 2013, it would continue to restart until the cows came home.

    I played around with the restart count configuration, but couldn't get it to be 'infinite'. I tried, -1, 0, and 99999. None of which actually worked.

    I think our solution to this problem is to move to our own error handling code. Something that resembles the examples that Roberto Stefanetti posted previously. The TryCatch examples are an event system. A quick prototype shows that this would work.

    If I get anything else from Microsoft, I'll update this thread.

  • Good Luck sh_scribe... YOU CAN DO IT!!!

  • So, after weeks of research, banging my head on rocks, walking around in circles counter clockwise, I finally figured it out.

    Short answer is that NAV 2013 R2 requires that you handle exceptions. ERROR exceptions can be thrown, but they have to be 'caught'. AND the referenced .NET code cannot throw unhandled exceptions. Any unhandled exceptions will halt the NAS.

    In the CAL code, we had to move a bunch of code around, pushing it down an additional layer. To correctly catch the exception, the code executes in the OnRun method of our new units. It's OK to throw an exception here as long as the calling method catches that error; like this:

    IF NOT SomeCodeUnit.RUN THEN BEGIN

        SomeText := GETLASTERRORTEXT();

        CLEARLASTERROR();

        HandThisErrorToDotNet(SomeText);

    END;

    Where SomeCodeUnit can throw ERROR until the cows come home. 

    Hope this helps future NAVrs.