Getting more insight into exceptions in NAV

  • Post category:Development
  • Post comments:4 Comments
  • Reading time:6 mins read

To continue my series about exception handling in NAV, this time I’ll discuss how to gain insight into exceptions in NAV. As I mentioned already, the GETLASTERROROBJECT function gives you an instance of System.Exception, actually of a class descending from it, which allows you to get more information about the context of the error that has just happened.

One part of the context you have already learned in the previous post – it’s the exception type. Since each exception is strongly typed, you can compare against each exception you get with its expected type.

Another important context element of the exception, which is kind of understood, is its Message property. It is of type System.String and it gives you the error message. Depending on what exactly you are doing, in most cases it will just match whatever you get from the GETLASTERRORTEXT function.

However, the most important context element of the System.Exception class is its InnerException property – it gives you access to details of the exception. You see, unlike errors in NAV, which are (or at least they used to be before NAV 2015) pretty flat, exceptions in the .NET world are quite complex. You can have an exception which contains an inner exception (which can in turn contain an inner exception) which tells you in more detail what exactly kind of exception happened.

To better understand this concept, let’s take a look at the following failing codeunit:

image

A no brainer, really. It plainly gives the division by zero error. Now take a look at the handler for this exception:

image

If you want to handle the division by zero exception, you are toast, because it shows this:

image

And – mind you – the division by zero is actually the System.DivideByZeroException type. Obviously, if you write some error handling code to handle the DivideByZeroException then the Exception instance in the code above by itself does not help.

However, its InnerException property (again, of type System.Exception) can help. So, change the code like this:

image

Run it, and you get this:

image

So, if you want to properly handle the exception of the System.DivideByZeroException, you would have to take a look at the InnerException property of the result of the GETLASTERROROBJECT function call.

However, in all likelihood, in most situations you’ll just want to look there anyway. There are a range of exception types that GETLASTERROROBJECT will give you, which don’t provide any valuable insight directly, and where you need to peek into the InnerException to actually understand what happened. Apart from the NavALException, another one that you’ll frequently see is this:

image

This one will happen whenever you make a .NET interoperability call, and it fails for whatever reason. You’ll just need to take a look inside of the InnerException to realize what exactly kind of exception it was.

And here we come to the point of my two previous posts – handling exceptions purely by name is baaaad. When handling the resulting exception directly, you are fairly safe, because – as I’ve shown – all of them are from the same Microsoft.Dynamics.Nav.Types.dll assembly. However, when handling inner exceptions,  these can come from any assembly in the world, and there is no guarantee that you might get two different exception types which have the same name, but are not of the same type. Yes, you could use the AssemblyQualifiedName property, but it’s both ugly, and it’s hardcoding. If you don’t believe me, just compare this:

image

… to this:

image

There is a big difference here, isn’t there?

Vjeko

Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has 4 Comments

  1. Vincent Vancalbergh

    I’ve written a recursive stack trace dump for Job Queue Entry errors. Helps immensily to track down errors that get sent to me via copy/paste.

  2. Harish

    Hello, Is there any work around to use GETLASTERROROBJECT functionality in 2013 R2. I am trying to get the error detail from web exception but not possible in 2013 R2 but works perfect in 2015

    1. Vjeko

      Sorry, not that I know of. I agree it would be great, but I don’t know of a way to get that information in 2013 R2.

Leave a Reply