JSON get_num validation

[Rob]

How does GET_NUM(KEY$,validation) work if validation is on?

Do you get an ERROR 11 for a missing key?

[Aaron Woodhouse]

Hi Rob!

Using the get_num function normally without the no_validation flag will return an error 11 if the key doesn't exist. It does some checks within the object's keys to make sure your provided key will work.

If you use the no_validation flag, it will skip this initial key check, and instead return an error 23 since it can't actually find the value.

It will return an error either way, but the key validator would tell you the issue is due to the key, not that there is no value.

[martinp]

Hey, I was having an issue with this but with GET_STR$

I see now if I pass GET_STR$(X$,1)  It returns null and no longer errors out. 

If I pass GET_STR$(X$,0) and X$ was not found in the data, the the error 11 isn't trapped

a serious error in: json.pvc 0484 error 11 results.  Shouldn't that  be trapped either way or did you want a hard error there?

Shouldn't the ,DOM=*NEXT   directive work there or?

Thanks for clarifying.

[martinp]

I'm still genuinely concerned about this using the GET_STR$(X$)  and it erroring within pvx code (json.pvc) if the string is not found unless I use GET_STR$(X$,1) vs just GET_STR$(X$) ?

[Mike King]

Do you enable the 'NE' system parameter? 

The problem you are having sounds a lot like the error is being generated in the object and it may be assuming that the error will be cascaded back up the stack which it would be if the 'NE' parameter is not enabled.

[Aaron Woodhouse]

Hi Martin,

The error 11 was meant to be a hard error, but you can use something like a try-catch to handle values not being found. Alternatively, you may have better use with the no_validation flag, since you can just compare the return value.

DOM=*next is meant for use with indexed data, but with associative arrays, and hence JSON, we store data as key-value pairs, which are not indexable. There are JSON Object functions that actually allow you to index it, but it should be avoided.

Like Mike mentioned; depending on what you are doing you could alternatively disable the 'NE' parameter.

[Mike King]

Generally internal errors being reported by objects or subprograms should be cascaded back to the user application.

I suspect that the json object is making some form of internal call that itself is returning an error that is not being properly cascaded back to your application.  This means if the 'NE' system parameter is set your application will fail with an error inside the object.

Normally when creating an object for which you anticipate returning an error from, if you need to invoke another method, object or subprogram that can return an error, you should explicitly provide an error trap that itself invokes an EXIT ERR.  This should allow the error condition to be passed back to your application regardless of the setting of 'NE'.

For Example:

Code Select Expand

Method1:
  ENTER A$,B$
  X$=_obj'SubMethod(A$, ERR=CascadeErr)
  ...
CascadeErr:
  EXIT ERR

[martinp]

Thanks for the discussions appreciate it!

Well I had 'NE' on, setting it off just brings me back to my program with the same error 11 still.  I was hoping ERR=*NEXT would then work on:

let TEX$=J'GET_STR$("edges."+str(I)+".texture",err=*next)

however it still does not.

The "Try-catch" worked to trap the error, I'm not used to that but could work.

The most elegant solution is just

let TEX$=J'GET_STR$("edges."+str(I)+".texture",1)

It just doesn't feel intuitive for me I would never remember that but I guess I would if I use it more.

Maybe this is normal working with JSON.

Long story short the data coming back sometimes had "edges.XX.texture" and some records, did not so I got the error.  My solution before the ",1" was to just load it into an array and I had no errors after.

Thanks again.

[Mike King]

You should just be able to disable the 'NE' and then re-enable it around the function call. That being said, I confirmed the operation of 'NE' using the following Object and test programs:

Object (with error cascading):

Code Select Expand

  def class "test"
 !
 ! Method
 !
  function method$(a$)
  enter a$
  x$=_obj'subMethod$(a$,err=CascadeErr)
  return x$
 !
 CascadeErr:
  exit err
 !
 ! Submethod
 !
  function subMethod$(a$)
  enter a$
  if a$="bad" \
   then exit 11
  return ucs(a$)
 !
  end defTest Program:

Code Select Expand

  oTest=new("test" for program)
  set_param 'NE'=0 ! Default setting
  gosub DoTest
 !
  set_param 'NE'=1
  gosub DoTest
 !
  end
 !
 DoTest:
  print "--------",'LF',"Test with 'NE'=",prm('NE')
 !
  print oTest'method$("good")
  print otest'method$("bad",err=RptErr)
  escape ! Should not get here
 !
 RptErr:
  print "Error exit taken"
  return
When I ran this I got the following:

->run "test
--------
Test with 'NE'= 0
GOOD
Error exit taken
--------
Test with 'NE'= 1
GOOD
Error exit taken

If you remove the ERR=CascadeErr from the object the error occurs if running with 'NE' enabled:

->run "test
--------
Test with 'NE'= 0
GOOD
Error exit taken
--------
Test with 'NE'= 1
GOOD
0007 LET x$=_obj'subMethod$(a$) ! ,err=CascadeErr)
Error #11: Record not found or Duplicate key on write

I would strongly recommend you use the ERR= branch to detect if a item is missing.  The return value of a null string ("") doesn't let you know if the value is undefined versus defined explicitly in the JSON as "".

[martinp]

Thanks Mike.  Setting with 'NE'=0 did the job with the ERR=*NEXT clause BUT only if I disabled my "ERROR_HANDLER"   LOL  Somehow that was overruling it. 

The ,1 still seems to work best with GET_STR after all this.

let X$=J'GET_STR$(Y$,1)

[Aaron Woodhouse]

We'll look further into error trapping for the JSON Object to make it work better using ERR.

In the meantime, another solution could be to use the 'Exists(key$) function, which would tell you if it's safe to get a value, since it'll return 1 or 0.