HttpService JSONDecode Not Failsafe

Feature Requests Engine Features
#1

It’s annoying that the HttpService JSONDecode method is not fail-safe, meaning that if it is given any invalid JSON then it asserts an nondescript error and stops everything. It should do something more sensible like return nil instead if invalid JSON is given.

My suggestion:
Either tell what is wrong with the given JSON, output the given JSON, or don’t have it break everything. It’s such a nondescript error and it does not help debug nor make things easier to program.

2 Likes
#2

Use:

#3

Well that’s super silly that it crashes stuff. It’d be nice if they fixed it, or else you need to make your own JSON decode function.

[quote] Use:

Documentation - Roblox Creator Hub [/quote]

Not too revelant.

#4

For now, you can use something like this:

local t
ypcall(function()
	t = game:GetService("HttpService"):JSONDecode(yourHttp)
end)
if (t) then
	print("Decoded")
else
	print("Not decoded")
end

However, hopefully they get that fixed up soon.

#5

Maybe I’m missing something.

There are two completely separate issues - 1. the error message for incorrect JSON data does not say where exactly the data is wrong, 2. instead of returning nil, failed JSON data generates an error.

Note that 2. does not mean that Roblox crashes - it just terminates the calling Lua thread unless you use pcall.

We will probably fix issue 1.
Why do you need nil if you can always use pcall/ypcall?

#6

[quote] Maybe I’m missing something.

There are two completely separate issues - 1. the error message for incorrect JSON data does not say where exactly the data is wrong, 2. instead of returning nil, failed JSON data generates an error.

Note that 2. does not mean that Roblox crashes - it just terminates the calling Lua thread unless you use pcall.

We will probably fix issue 1.
Why do you need nil if you can always use pcall/ypcall? [/quote]

pcall/ypcall is a bad practice. Any method which can error should always return nil with an error message on error.

#7

You can also use Spawn function in order to prevent your script from dying, tho I’d prefer getting nil returned.

#8

Unfortunately, methods follow the convention of only being able to return one value. Yes, they can return a Tuple, which interfaces with Lua’s multiple return values. But that hides the actual underlying value, which is not so neat when the method is generally not throwing errors.

The only other good way to propagate an error is to just throw an error, which can be picked up by pcall. This appears to be how ROBLOX does error handling, even if they don’t mention it anywhere. Whatever hit in performance that is taken by using pcall is probably fine for most methods. Methods that require speed (i.e. Terrain.SetCell) are designed to never throw errors. Well, at least I hope they are.

That said, what should be made clear is whether a method can potentially throw an error. A “canError” tag in the API dump would be nice.

#9

Unfortunately, methods follow the convention of only being able to return one value. Yes, they can return a Tuple, which interfaces with Lua’s multiple return values. But that hides the actual underlying value, which is not so neat when the method is generally not throwing errors.

The only other good way to propagate an error is to just throw an error, which can be picked up by pcall. This appears to be how ROBLOX does error handling, even if they don’t mention it anywhere. Whatever hit in performance that is taken by using pcall is probably fine for most methods. Methods that require speed (i.e. Terrain.SetCell) are designed to never throw errors. Well, at least I hope they are.

That said, what should be made clear is whether a method can potentially throw an error. A “canError” tag in the API dump would be nice.[/quote]

That would also be nice, too.

#10

Why is it a bad practice?
As mentioned by Anaminus this is the way most methods in Roblox communicate errors to the caller.

canError metadata can only be added manually, so it will get out-of-sync with the actual behavior very fast.

#11

Consider it a form of documentation. I guess it doesn’t have to be done through the API dump, but it would still be nice to have.

I remember this. Back in the day, people decided using pcall was bad practice because they thought that it would let people get away with writing sloppy code, which should be written to not throw errors in the first place. I don’t think fact that ROBLOX methods can throw errors was ever involved.