Home > Article > Backend Development > Calling json.Unmarshal within the UnmarshalJSON function does not cause stack overflow
When processing JSON data, we usually use the json.Unmarshal function to parse the JSON string into a structure in the Go language. However, calling the json.Unmarshal function inside the UnmarshalJSON function may cause a stack overflow error. This is because the UnmarshalJSON function calls itself again when parsing JSON data, causing an infinite loop. To avoid this, we can use the Decode method of json.Decoder to parse the JSON data instead of calling the json.Unmarshal function directly. Doing this ensures that stack overflow problems will not occur and ensures the robustness and performance of the code.
I would like to perform some additional steps to initialize the data structure in my implementation of UnmarshalJSON
. Calling json.Unmarshal(b, type)
in this implementation will naturally cause a stack overflow.
JSON decoder keeps trying to find if there is a custom UnmarshalJSON
implementation before calling json.Unmarshal
again.
Is there any other way to do this? Wouldn't just calling the underlying default implementation cause this problem?
A simple and common way to avoid/prevent this situation is to use the type
keyword, and Use typeconversion to pass a value of that type (which can be type-converted if it is your original value, since the new type has the original type as its underlying type).
This works because the type
keyword creates a new type, and the new type will have zero methods (it will not "inherit" the base type's methods).
Will this incur some runtime overhead? no. Quoted from Specification: Conversion:
Let's look at an example. We have a Person
type with a number Age
, and we want to make sure that Age
cannot be negative (less than 0
).
type Person struct { Name string `json:"name"` Age int `json:"age"` } func (p *Person) UnmarshalJSON(data []byte) error { type person2 Person if err := json.Unmarshal(data, (*person2)(p)); err != nil { return err } // Post-processing after unmarshaling: if p.Age < 0 { p.Age = 0 } return nil }
Test it:
var p *Person fmt.Println(json.Unmarshal([]byte(`{"name":"Bob","age":10}`), &p)) fmt.Println(p) fmt.Println(json.Unmarshal([]byte(`{"name":"Bob","age":-1}`), &p)) fmt.Println(p)
Output (try on Go Playground):
<nil> &{Bob 10} <nil> &{Bob 0}
Of course, the same technique also applies to custom marshaling (MarshalJSON()
):
func (p *Person) MarshalJSON() ([]byte, error) { // Pre-processing before marshaling: if p.Age < 0 { p.Age = 0 } type person2 Person return json.Marshal((*person2)(p)) }
Test it:
p = &Person{"Bob", 10} fmt.Println(json.NewEncoder(os.Stdout).Encode(p)) p = &Person{"Bob", -1} fmt.Println(json.NewEncoder(os.Stdout).Encode(p))
Output (in the same Go Playground example):
{"name":"Bob","age":10} <nil> {"name":"Bob","age":0} <nil>
A very similar problem is when you define the String() string method for a custom text representation of the
的自定义文本表示定义 fmt
package, and you want to To use the default string representation that you modified. Read more about it here: Difference Between t and *t
The above is the detailed content of Calling json.Unmarshal within the UnmarshalJSON function does not cause stack overflow. For more information, please follow other related articles on the PHP Chinese website!