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.
There is one situation in particular that’s adding a cherry on top of all of problems, and it’s the creepy “A script error has occurred” error message. It’s the equivalent of the BSoD.
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.
Continue reading Getting the exception type from the GETLASTERROROBJECT
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. You have only one possibility to actually capture the error, and it’s the IF CODEUNIT.RUN construct, and it’s limited because you can do it only once per transaction, and if you want to do it twice, you must COMMIT your transaction first.
But still, capturing an error is one thing; actually handling it is quite a different thing altogether.
Continue reading Better error handling in NAV 2015
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.
To make it short: if something works on one platform and fails on another platform, it’s not the fault of the Web service being called, it’s the fault of the caller platform.
As I said in the last post, there are two ways, or platforms if you wish, native to .NET Framework, which you can use to connect to any Web services. And they don’t work exactly the same.
Continue reading Web Reference vs. Service Reference, Part 2
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.
And then I found out it was not just a report.
It just didn’t want to execute in production. Whatever I did I just got a strange error message, something I never saw before. Ever.
Continue reading Strange errors in RoleTailored Client RDLC reports