When we mention empty string in GUID then system is not throwing correct Error

[srinivasbanny]

i have written code

IF SMTPMailSetup."Password Key" = '' then
Error('Password is empty ');

but when i tried to execute the above code system is throwing error instead of giving empty string error

Invalid format of GUID string. The correct format of the GUID string is: CDEF7890-ABCD-0123-1234-567890ABCDEF where 0-9, A-F symbolizes hexadecimal digits.

solution should be, compiler should find the issue and should not allow to create app

[srinivasbanny]

Al Compiler version is 3.0.106655
Build version is 14.0.29530

[AskeHolst]

Have you tried comparing with a null Guid?
It sounds like the comparison failing due to an empty string not being castable to Guid.

[charlespockert]

A null GUID is a GUID will zeros in every position - you can't compare a GUID to a string without that string being castable to a GUID.

The string '' is not a valid GUID so this doesn't look like a bug, more like a coding error.

Is the "Password Key" a GUID type?

[AskeHolst]

It is indeed a GUID field:

So the solution is comparing with a null Guid (just define a variable of type Guid a do NOT give it a value).

I guess you could wish for the compiler finding this at compile time to avoid getting it at runtime.
But type casts are hard to check for without limiting freedom. We want to be able to have an implicit cast from String to Guid, but the compiler should check immutable strings being valid for casting at compile time - though one.

[charlespockert]

@AskeHolst you can just use:

IsNullGuid() built-in function for this.

[AskeHolst]

Even better solution with the IsNullGuid(), lets hope the original poster @srinivasbanny is reading this.

It still leaves the general compiler question of checking types at compile time. Which is why this question might be relevant here.

[srinivasbanny]

@AskeHolst exactly that is what my question is, if i am trying to define this as a string then compiler should give some error not to allow us to build the app at least

[charlespockert]

@AskeHolst but there's no reason to use a string as a way to check against this GUID here. GUID literals could be useful in other cases - there are a few places in NAV/BC where a notification ID is re-used so that the notifications don't stack (for example the Dynamics 365 sync. code). This GUID is a string literal which is casted to a GUID at runtime, but there's no reason for it to be in future if literals were implemented.

@srinivasbanny I don't follow in your case here - you need to test the value of "Setup Key", not the string literal so there shouldn't be any need for the compiler to check any strings.

As stated though, GUID literals might be useful in future in order to create compile time constants.

[AskeHolst]

@charlespockert I think you are missing the point of compiler checks: That developers make mistakes.
So you are right, there is no reason to make the mistake, but it happens. What @srinivasbanny is asking for, is a check to tell him, at compile time, that he made a mistake by comparing an empty string with a Guid. Just another request for enhancing the compiler.

[charlespockert]

@AskeHolst I'm not missing the point, I'm just saying that IsNullGuid and guid literals would solve this in a better way.

I agree, developers make mistakes, but it's a developers job to educate themselves on the type system and understand not to expect a string cast (which could be any value at runtime) to be checked at compile time.

[lukacetko]

AL behaviour seems to have changed here.
The following code throws the above error in build 14.0.* and works as expected in build 13.0.*.

var
	testGuid: Guid;
begin
	if testGuid <> '' then;
	Message('OK');
end;

Tested with on-prem BC 13 cumulative upd 3 (no error) and on-prem BC 14 (error).

There are multiple fixes possible, but it is curious that this AL behaviour has been changed.
My question is was the change in behaviour intentional?

[atoader]

Hi! The behavior you see in 14.0.* is the correct one and it is mostly related to legacy code. In C/AL, whenever a Guid was compared with a String-like type, behind the scenes, the String was parsed into a Guid and the comparison was performed between two Guids.
If the string cannot be parsed into a Guid, an exception is thrown at runtime.
I agree that this is not ideal, but we need to keep the existing behavior because existing code depends on it.