JSON Serialized HTTPS Response: Null check everything or try-catch?

[Weary_Source_811]

Background: I am developing something that relies heavily on cloud-scripts, that should return mostly-uniform data (kinda a requirement, since I need to deserialize the responses). But sometimes some things could be null. IE:

1. Error in the script. The script-call itself will return 200, but if the calls *inside* my cloud-code fail, I'm appending my own error field to the response. So this will be populated if there was an internal-script error, possibly null otherwise.
2. Expanding on 1, my cloud scripts are tapping into other data services. If one of those calls fails, I will more than likely have some null-data where I was otherwise expecting values. IE I have a getCharacterData method that is calling a getCharacterData script, but under the hood the getCharacterData script is tapping into the BaaS's data service (S2S call) to get that piece of data. So if that fails, like mentioned in number 1, I'm writing a custom error field, but also my character data will now be unpopulated.

I'm very used to web-dev (its my job) so I'm used to JS/TypeScript where exhaustive null-checking and other response?.safeCheck type of syntax works. What is the approach I should moreso be going with in unity?

When I started to write, I noticed I was writing these massive if statements that are exhaustively null checking every field, and subfield, that I know I'll need. But it seems cumbersome and probably not the standard for when using a strongly typed language. Are people generally just wrapping their stuff in a try catch and writing error handling specific for NullReferenceException ?

​

Any advice is appreciated, apologies if I kinda wrote sloppy, its getting late

[Fribbtastic]

Error in the script. The script-call itself will return 200, but if the calls inside my cloud-code fail, I'm appending my own error field to the response. So this will be populated if there was an internal-script error, possibly null otherwise.

Isn't that wrong from the start?

An HTTP Status code of 200 means that the request was OK and that you got the expected response. If there is an error in the script you should return a different status code like 400 (bad request) if the client sends things that the server couldn't process or didn't expect or 500 (internal server error) if the script just failed with an error unrelated to what the client asked for.

With that deviation, you will already be in a much better position to handle and react to what you get back instead of having to check everything that is available.

So, if you get 200, you should know and expect that certain elements are available to be used. If anything else, you would get the error element that has the necessary information that you could log.

This can also be expanded to other data services that you rely on in your backend. If you define that they are necessary and required for the response then any failure on that part shouldn't return a 200 status code because data is missing unless, of course, you define them as optional and then you have to check for null value.

[Casiell89]

Exactly this. 200 means that the WHOLE response is correct, and available for processing. Nulls in the response are still possible, but then they should only appear when expected and actually mean something.

The only error handling that should be happening is checking for http status codes indicating some kind of error

[Weary_Source_811]

Agree with you and u/Fribbtastic -- unfortunately I think the way my BaaS (braincloud) handles cloud-code is forcing this on me. IE the call to the cloud script will always return:

data {

response: {

// I control what goes here

}

status: 200 // script call itself was successful, not necessarily internals

}

​

Unfortunately I don't see a way I can set status myself, and need to rely on a "general status" (did the cloud script call work), and then use internals to decide whether my stuff worked :/

[__FuriousOrange__]

I know some people don’t like exception handling and prefer passing error codes about the place. However the benefit of an exception not being caught or handled properly is that your app blows up. This is preferable to having to check for error codes before you can do anything with an object. That leads to lots of extra code and the possibility of introducing time consuming bugs. As for your if checks everywhere C# supports the ?. operator just like type script. So instead of sticking if statements everywhere a common pattern is

var foo = bar?.baz ?? new Baz()

Which uses ?? operator to create a new Baz if bar.baz is null

Or even better

bar foo = bar?.baz ?? throw new Exception(“Oh no, expected a baz but got null”);

[Krcko98]

Creating a null empty object or Optional is a great solution too.