NAV TechDays 2014 Pre-conference goodies

So, NAV TechDays 2014 have started, again, with the pre-conference sessions that were all sold out and packed full.

Today I had an extraordinary pleasure to teach the advanced .NET Interoperability concepts to 15 people that came from all over the world, from Brazil to Australia. It was an interesting workshop, challenging – I must say (thanks to Rafael who made me improvise a solution to a typical DotNet limitation), and I am looking forward to delivering two more sessions about .NET and Control Add-ins tomorrow, and on Friday.

As promised, I am making the materials from the presentation available for the download, in case you want to learn the same stuff the attendees learned today.

(more…)

Continue Reading NAV TechDays 2014 Pre-conference goodies

GETLASTERROROBJECT vs. GETLASTERRORCODE

Good. At this point we know everything about exception types, what they are, how to obtain them, how to compare them (at least directly). All of these have suddenly become relevant now that we have GETLASTERROROBJECT function in NAV 2015.

But an old friend is still around, the GETLASTERRORCODE function, what about it? Why do we need to bother with GETLASTERROROBJECT when we have a simpler approach, with less peeking into inner exceptions, less reflection, less spooky, obscure .NET internals?

(more…)

Continue Reading GETLASTERROROBJECT vs. GETLASTERRORCODE

Getting more insight into exceptions in NAV

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.

(more…)

Continue Reading Getting more insight into exceptions in NAV

Getting the exception type from the GETLASTERROROBJECT

In my last post I have introduced the GETLASTERROROBJECT function that returns you the instance of the System.Exception class, representing the actual exception that has happened.

To properly handle exceptions in an unambiguous way, you must use the exception type, not its name, so it is important to get the actual System.Type representing the exception type.

Sounds easy, but it’s not quite so.

(more…)

Continue Reading Getting the exception type from the GETLASTERROROBJECT