Blog

While it may be a cold day in hell before we see any TRY..CATCH constructs in pure C/AL, we are all far more lucky when it comes to .NET interoperability. In this blog post I’ll (re)present the same concept I demonstrated during NAV TechDays 2013 last year in Antwerp, because I am quite sure this nifty little trick got lost under piles of other posts on this blog.

When interacting with custom controls on your pages from C/AL, you must be absolutely sure that the control has been instantiated. If it is not, you’ll get an error such as this: The reason why this happens is that C/AL code gets to execute before the page has been rendered, and thus also before the custom controls have been instantiated.

If you want to rollback the database changes, but do not want the code execution to end, simply call ASSERTERROR ERROR(”); The ERROR(”) will quietly rollback the data changes, and the ASSERTERROR will capture the error, allowing the code execution to continue.

Did I CATCH your attention yet? At least I did TRY. Now that I have completed my series on exception handling in C/AL , a very valid question pops up: why don’t we have try..catch syntactical constructs in C/AL, the way we have it in other programming languages?

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?

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.

Yesterday, thanks to @sforkmann and his blog at navision-blog.de , I have learned of the existence of Statical Prism . I’ve given it a try today, and I am pretty happy – that was just the tool I needed. I won’t give a complete overview of it here, I’ll just explain that it’s a tool that reads your…

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.

You may love C/AL as a language, but there is an area in it that you must just hate. It’s the error handling. Plainly put, and being actually quite positive about it, in NAV, error handling just sucks. If an error happens, it happens.

One more great Directions EMEA event is over, and it was a great experience again. I am a bit sorry, though, that my main focus was delivering presentations, so I enjoyed myself less mingling around, meeting new folks and consuming content. But it was still a great event.