AL --- Order of Evaluation in Conditional Expression

(1) Share

Report

Posted on by Greg Kujawa

633

Having previously coded in Ruby, Java, C#, Javascript, etc. for years now, I recall there being some subtle difference in terms of evaluation logic between languages. When it comes to BC 365 AL, I am hitting a sporadic error that I am having trouble getting feedback from our users about. The error is the classic "startIndex cannot be larger than length of string. (Parameter 'startIndex')," which leads me to believe that the implied startIndex in the substring is the culprit.

Here below is the place in my code where the error is being thrown. If the conditions are being evaluated from left to right, then I'd think the conditionals would fail if the InputString text wasn't the required length. So the substring wouldn't even come into play at the end of the conditions. Or am I missing something?

if (Text.StrLen(InputString) > 20) and (InputString.StartsWith('01')) and (InputString.Substring(17, 2) = '21') then begin

Categories:

Dynamics 365 Business Central

All responses (5)

Answers (1)

Verified answer

Greg Kujawa 633 on at

Like (1)

Report

AL --- Order of Evaluation in Conditional Expression

Here is a screen shot of the GitHub issue I opened in the Microsoft AL project. Apparently, this behavior is a holdover from legacy C/AL. Going back to C, I can't think of many programming languages that don't short-circuit conditional expressions!
Greg Kujawa 633 on at

Like (1)

Report

AL --- Order of Evaluation in Conditional Expression

Here is an example of the same logic being applied to this string in PowerShell. Only if the SubString expression is the evaluated at the beginning of the conditionals is an exception raised. But if a SubString expression isn't evaluated, since the previous expressions have already failed, there is no exception raised. This doesn't seem to be the case when it comes to AL?
Greg Kujawa 633 on at

Like (1)

Report

AL --- Order of Evaluation in Conditional Expression

Quick follow-up on this. Now that I'm debugging and trying to force different input string values, I see where the error is occurring for examples. My procedure errored out using this value
01000000IT1092012

This value is only 17 characters long. So the expression above shouldn't even hit the substring conditional, if the expressions are being parsed from left to right. I even wrapped the first two expressions in parenthesis, assuming this would force them to be evaluated first. Before hitting the final substring expression.

@YUN ZHU, any ideas?
Greg Kujawa 633 on at

Like (2)

Report

AL --- Order of Evaluation in Conditional Expression

Thanks for taking the time to test this out! I still cannot wrap my head around why this line would throw that error. I cannot duplicate it either, so debugging on my end hasn't revealed anything. Looking at the logic of this conditional statement, I can't see how in the world it would ever throw an exception?

Assuming the AL stack trace aligns with my AL source code, this is definitely where the procedure is falling over. For an extension update I will wrap the procedure in a TryMethod, to handle the error and present the user with a message box informing them of the InputString value that couldn't be parsed. That way I can see a quick screen shot of what's going on.
Suggested answer

YUN ZHU 74,115 Super User 2024 Season 2 on at

Like (2)

Report

AL --- Order of Evaluation in Conditional Expression

Hi, I briefly tested your code and encountered no errors.

I also split it and debugged it, and there was no problem

Hope this helps.

Thanks.

ZHU