InvalidJsonType class

From m204wiki
Jump to navigation Jump to search

Json objects simulate JavaScript untyped variables. However, many Json functions only make sense for specific underlying Json data. For example, the Add function only makes sense if the underlying json object is an Array. If a function applied to a Json object is invalid for the underlying object, an InvalidJsonType exception is thrown.

To create an InvalidjsonType exception yourself, you typically use a SOUL Throw statement with an InvalidJsonTyoe New constructor. This statement must be issued from within a method, and it can only be caught by the code that calls the method. For example, the following statement throws an InvalidJsonType exception:

throw %(invalidJsonType):new(type=array, method="MyJsonMethod")

Remember that you catch an exception with the Catch statement; if an exception condition occurs outside a Catch for it, the request is cancelled.

The InvalidJsonType class, like the Json class is available as of Model 204 7.6.

The InvalidJsonTypes methods

The following are the available InvalidJsonType class methods.

MethodDescription
MethodNameType of object for invalid method
NewCreate a new InvalidJsonType object
TypeType of object for invalid method

The methods in the class are described in the subsections that follow. In addition:


New constructor

Create a new InvalidJsonType object (InvalidJsonType class)

This Constructor generates an instance of an InvalidGZipData exception. The New method format follows:

Syntax

%invalidJsonType = [%(InvalidJsonType):]New( Type= jsonType, MethodName= string)

Syntax terms

%invalidJsonType A reference to an instance of an InvalidJsonType object.
[%(InvalidJsonType):] The class name in parentheses denotes a Constructor..
jsonTypeA JsonType enumeration value that indicates the underlying JSON type of the object to which the invalid method was applied.
stringThe name of the method that encountered the error.

Usage notes

  • Json object tree can be created from data received from an outside data source that was generated via the Json Parse function. If the external data source is considered 100% in terms of sending JSON data with a known format, the data could be extracted without worries about InvalidJsonType exceptions. However, if there is a concern that the data will not be exactly what is expected, one should either test each object for the expected datatype via the Type function or wrap the data extraction inside a Try/Catch InvalidJsonType. Obviously, the latter requires less effort and is more efficient. For example, if an application expects an order to come in as an array of objects with a product name, code, quantity, and price but the source is not 100% trustworthy, one can do something like:

    try for %i from 1 to %order:count %name = %order(%i)("name"):stringValue %code = %order(%i)("code"):stringValue %quantity = %order(%i)("quantity"):numberValue %price = %order(%i)("price"):numberValue ... process the order item end for catch invalidJsonType ... deal with the error end try

    The Try/Catch adds no overhead to the processing but makes it easy to trap a malformed request.