Error

Capturing unhandled errors in JavaScript Control Add-ins

  • Post comments:5 Comments
  • Reading time:5 mins read

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.

But the overlord of trial and error in NAV is development of control add-ins in JavaScript. JavaScript itself is making it difficult in the first place, and then integration with NAV makes it even harder.

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.

(more…)

Continue ReadingCapturing unhandled errors in JavaScript Control Add-ins

Getting the exception type from the GETLASTERROROBJECT

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

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 ReadingGetting the exception type from the GETLASTERROROBJECT

Better error handling in NAV 2015

  • Post comments:5 Comments
  • Reading time:5 mins read

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.

(more…)

Continue ReadingBetter error handling in NAV 2015

Web Reference vs. Service Reference, Part 2

  • Post comments:2 Comments
  • Reading time:5 mins read

imageA 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.

(more…)

Continue ReadingWeb Reference vs. Service Reference, Part 2

Strange errors in RoleTailored Client RDLC reports

  • Post comments:3 Comments
  • Reading time:4 mins read

olddogWe 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.

(more…)

Continue ReadingStrange errors in RoleTailored Client RDLC reports