AL --- Order of Evaluation in Conditional Expression

(1) Share

Report

Posted on by Greg Kujawa

583

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

I have the same question (0)

All responses (5)

Answers (1)

Suggested answer

YUN ZHU 95,739 Super User 2025 Season 2 on at

Like (2)

Report

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

Was this reply helpful? Yes No
Greg Kujawa 583 on at

Like (2)

Report

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.

Was this reply helpful? Yes No
Greg Kujawa 583 on at

Like (1)

Report

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?

Was this reply helpful? Yes No
Greg Kujawa 583 on at

Like (1)

Report

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?

Was this reply helpful? Yes No
Verified answer

Greg Kujawa 583 on at

Like (1)

Report

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!

Was this reply helpful? Yes No