Error

Not that I am saying it’s a good thing, but trial and error is a fairly common approach to debugging in the NAV world. We’ve all done it. Heck, even with the comprehensive testability framework built in, we all still do it more often than we’re happy to admit while sober.

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.

A beauty of Web services is that they don’t need to care at all about who’s consuming them. Whether there is .NET on Windows, Java on Linux or some proprietary stuff on an iPad on the other end, they do exactly the same stuff.

We old dogs really have to learn new tricks with RTC (RoleTailored Client), as I found out couple of days ago. A customer of mine asked me for a quick report. I don’t typically do reports, but I thought— “not a big deal, it’s just a report” —so I fixed it, tested it, made sure it worked, then deployed it to production.

“Perfect is the enemy of good” , a smart person said once. Another one said: “If it works, don’t mess with it.” So, I messed with it. I was trying to make it perfect. Over past couple of weeks, you might have experienced downtimes, or even errors such as 403 Access Forbidden or similar here on my blog.

If you try exposing Page 5 Currencies as a Web service in Microsoft Dynamics NAV 2009, and then consuming this web service through a .NET application, you are almost guaranteed to encounter some unhelpful and generic XML errors that give you absolutely no clue about what exactly, where and why, went wrong.

Don’t you just love when users come up with new feature ideas at a microprocessor clock rate. Even before you finish developing one, five new requests pop up. This is a disease, and it’s called featuritis ! Featuritis doesn’t mean the features are just sporadically requested and developed ad hoc.

They say the only constant is change. I’d say that the only other constant is error. We humans tend to err. Give a repeatable task to a human, and they’ll mess it up every once in a while. Some call it the human factor . One of the many repeatable tasks in Microsoft Dynamics NAV is setting up items.

There is only one way to abort a user action in Microsoft Dynamics NAV: by using the ERROR function. This function essentially stops the execution of all code, and prevents completion of the user action, whatever such action might be. One of typical situations where ERROR is used to prevent user action is during validation of a new value in a field.