mORMot Open Source

Sabbiolina

Member

Registered: 2014-05-20

Posts: 120

[JSON] New behavior of _json

Hi AB,
in last 2 weeks you changed the function _json:

before _json ('') was returning a null variant
now returns a 'unassigned'

[..]
var
res:RAWutf8;
vres:variant;
begin
res:='';
vres:=_json(res);

if varisnull(vres) then exit; // now don't fire

first if you converted an empty string the variant was null, not anymore.
is the desired result or a bug?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: [JSON] New behavior of _json

Feature?
There is no definition of '' in JSON.
In fact, '' is no valid JSON content, whereas 'null' is a null JSON object.
So unassigned sounds definitively better than null.

Sabbiolina

Member

Registered: 2014-05-20

Posts: 120

Re: [JSON] New behavior of _json

But there's null us that there is no result, a mistake.

When you ask for an item that a function, returns null if you know that there is a valid result.

I agree on the speech of _Json ('') but we must remember that in a LATE BINDING case: an element not present is not empty but null.

so I am not sure that you want to change this result in case of error.

I think it's best to use a varIsNull to find fault.
I think having to test alternately varIsnull and / or varIsempty eventually bring more mistakes than good.

Ultimately, also to avoid having to change the past procedures, it would be better that the function returns a null _json on error and not an empty.

BBackSoon

Member

Registered: 2014-11-15

Posts: 41

Re: [JSON] New behavior of _json

Feature?
There is no definition of '' in JSON.
In fact, '' is no valid JSON content, whereas 'null' is a null JSON object.
So unassigned sounds definitively better than null.

I have to agree with Sabbiolina here.
If you pass a WRONGLY-formatted JSON string (or anything that cannot be decoded as JSON) it would be better to return a NULL variant, not an empty variant.
Not only because breaking backwards compatibility is a bad practice (would require coders to go over everything they already wrote in the past), but also because if what I pass as an argument to that function is not a JSON then it's much more correct to return NULL rather than empty.

NULL tells the story: "hey dude that was NOT a JSON"
EMPTY is dangerously bi-valent: I could have EMPTY if I pass a valid empty JSON or an invalid one... and then how do I tell the difference?

I most definitely vote to bring back the old behavior: whatever invalid parameters, just return a NULL variant.
Thank you.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: [JSON] New behavior of _json

But how do you know that the supposed JSON input was 'null' and not 'whatever bulk content'?

Please remember that:
- There is no notion of 'empty' in JSON.
- '' is invalid JSON

So returning unassigned (TVarData.VType=0) in case of '' just means that the input was invalid JSON.

Sabbiolina

Member

Registered: 2014-05-20

Posts: 120

Re: [JSON] New behavior of _json

Here the first bug with emptyvar:

procedure TForm1.Button6Click(Sender: TObject);
var
 V:variant;
 res:RAWutf8;
begin
 res:='{mytime: '+floattostr(now)+'}';
 v:=_json(res);


 with TdocVariantData(v) do
  addvalue('day',dayofweek(now));

 memo1.Lines.Add('Result: '+rawutf8(v))
end;

initialization
if SetThreadLocale($0409) then
  GetFormatSettings; // resets all locale-specific variables to LCID_US

with codepage initialization all is ok:
Result: {"mytime":42011.7791793634,"day":4}

but with italian codepage (comma for decimals):
Result:

With NO EXCEPTION!!!

I think also that it is better to think about the path taken by the compiler:
if a variant there is better to return a null.

a null value will become an exception and will be manageable.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: [JSON] New behavior of _json

The _Json() does not raise an exception, but unassigned for not correct JSON content.
As stated by its documentation:

will return an Unassigned variant if JSON content was not correctly converted

If you do not set the format settings, your floattostr() returns not a point, but a comma for decimals, so the input is not valid JSON, so it returns unassigned.
You just give invalid JSON input.
Do not cal a bug what is not a bug.

EMartin

Member

From: Buenos Aires - Argentina

Registered: 2013-01-09

Posts: 337

Re: [JSON] New behavior of _json

I have to agree with @ab. If a JSON string is invalid is logical that the parse return an unmanageable data type, similar to SuperObject that return nil when the JSON string is invalid.

Regards.

---

Esteban

Sabbiolina

Member

Registered: 2014-05-20

Posts: 120

Re: [JSON] New behavior of _json

with 2 type of unmanageable data type we must add this:

function VarIsNullEmpty(const V: Variant): Boolean;
begin
  Result := (FindVarData(V)^.VType = varNull) or (FindVarData(V)^.VType = varEmpty);
end;

@ab
bug is here:
with TdocVariantData(v) do addvalue('day',dayofweek(now));

addvalue must check if V is valid before adding.
do you agree?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: [JSON] New behavior of _json

No, the use case is not to force typecasting via TdocVariantData(v) but use explicit check method.