Any function that accepts only one parameter can be called as if it were a property, and this applies to built-in system functions, your own custom functions, and even .NET…
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.
So, let’s learn how to do try..catch..finally for .NET interoperability C/AL code, using mostly C/AL code.
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…
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?