Json.Decode.decodeValue runtime error

[pauldijou]

If you have a recursive JavaScript object and you try to apply a simple decoder on it like that:

myString = Json.Decode.decodeValue Json.Decode.string myRecursiveObject

This will crash at runtime because it tries to stringify the recursive value when generating the error message which will fail with TypeError: Uncaught error: Converting circular structure to JSON

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[pietro909]

I also incurred in that problem once. But do you think is Elm's error? The decoder is meant to decode JSON data, and the JSON spec doesn't mention references.

I think you shouldn't try to parse a generic JavaScript Object unless it is JSON compliant.

[pietro909]

I also incurred in that problem once. But do you think is Elm's error? The decoder is meant to decode JSON data, and the JSON spec doesn't mention references.

I think you shouldn't try to parse a generic JavaScript Object unless it is JSON compliant.

[pauldijou]

Yeah, I've been asking myself the same question. But JSON is actually a String which follow a specific syntax. According to that, Json.Encode functions should all return strings, Json.Encode.Value should probably not exist, and Json.Decode.decodeValue would make no sense. That's one way to solve the problem.

But, if keeping Json.Encode.Value, it's dangerous because you can pass anything as a Json.Encode.Value inside a port, even if it is a JavaScript function or a recursive object. There is no check at all.

So, if the goal is to prevent compiled code to crash at runtime, I still think there is a problem somewhere. Not sure if the best solution is to prevent Json.Encode.Value at all, or just checking them inside ports, or adding a try/catch inside toString and decoders.

[pauldijou]

Yeah, I've been asking myself the same question. But JSON is actually a String which follow a specific syntax. According to that, Json.Encode functions should all return strings, Json.Encode.Value should probably not exist, and Json.Decode.decodeValue would make no sense. That's one way to solve the problem.

But, if keeping Json.Encode.Value, it's dangerous because you can pass anything as a Json.Encode.Value inside a port, even if it is a JavaScript function or a recursive object. There is no check at all.

So, if the goal is to prevent compiled code to crash at runtime, I still think there is a problem somewhere. Not sure if the best solution is to prevent Json.Encode.Value at all, or just checking them inside ports, or adding a try/catch inside toString and decoders.

[ChristophP]

I just had the issue as well. I was

• decoding a circular JS object
• with decodeValue
• and no stringifications

Everything worked when the decoding succeeds but when the decoder failed, JSON.stringify() is called to construct a proper error msg.
Would be cool if this line line were wrapped in a try catch https://github.com/elm-lang/core/blob/5.1.1/src/Native/Json.js#L235

[ChristophP]

I just had the issue as well. I was

• decoding a circular JS object
• with decodeValue
• and no stringifications

Everything worked when the decoding succeeds but when the decoder failed, JSON.stringify() is called to construct a proper error msg.
Would be cool if this line line were wrapped in a try catch https://github.com/elm-lang/core/blob/5.1.1/src/Native/Json.js#L235

[rupertlssmith]

Did anyone capture the runtime exception that is thrown at: https://github.com/elm-lang/core/blob/5.1.1/src/Native/Json.js#L235 ?

I want to know if it is an out of stack space exception from infinite looping, or if it is some other exception indicating that javascript spotted the infinite loop.

If its an out of stack space exception, then wrapping it in a try/catch is not a good idea.

Also, the code has changed a lot since the 5.1.1 release, so this might already be fixed. Will take a look.

[rupertlssmith]

Did anyone capture the runtime exception that is thrown at: https://github.com/elm-lang/core/blob/5.1.1/src/Native/Json.js#L235 ?

I want to know if it is an out of stack space exception from infinite looping, or if it is some other exception indicating that javascript spotted the infinite loop.

If its an out of stack space exception, then wrapping it in a try/catch is not a good idea.

Also, the code has changed a lot since the 5.1.1 release, so this might already be fixed. Will take a look.

[rupertlssmith]

Seems to be fixed here:
https://github.com/elm-lang/core/blob/master/src/Elm/Kernel/Json.js#L327

On failure the JSON is returned as a Value.

[rupertlssmith]

Seems to be fixed here:
https://github.com/elm-lang/core/blob/master/src/Elm/Kernel/Json.js#L327

On failure the JSON is returned as a Value.