Unmarshaling json in Go (error checking missing)

[alexander....@gmail.com]

Hi, as I understand Go presumes strict error handling. So why there is no way to way to check if json was unmarshaled correctly to struct with values (not pointers)?
Assume we have a struct

type My struct {
    MissingField string
    ExistingField string
}

and json "{"existingfield" : "somevalue"}".

The values of My will be My{MissingField:"", ExistingField:"somevalue"} and no error at all will be returned. I had no MissingField in json but nevertheless the unmarshaling was done correctly. You can make it in the following way:

type My struct {
    MissingField *string
    ExistingField *string
}

and it will work as expected. But what about struct without pointers? Is it not necessary to check values or what? :)

[Ian Lance Taylor]

It's a design choice. There is no need to have your Go struct exactly
match your JSON format. Since you can detect which fields were
present by using pointers, you can write your code to work in whatever
way seems best for your application.

Ian

[Konstantin Khomoutov]

On Tue, 28 Jan 2014 06:24:53 -0800
Ian Lance Taylor <ia...@golang.org> wrote:

> > Hi, as I understand Go presumes strict error handling. So why there
> > is no way to way to check if json was unmarshaled correctly to
> > struct with values (not pointers)?
> > Assume we have a struct
> >
> > type My struct {
> > MissingField string
> > ExistingField string
> > }
> >
> > and json "{"existingfield" : "somevalue"}".
> >
> > The values of My will be My{MissingField:"",
> > ExistingField:"somevalue"} and no error at all will be returned. I
> > had no MissingField in json but nevertheless the unmarshaling was
> > done correctly. You can make it in the following way:

[...]

> It's a design choice. There is no need to have your Go struct exactly
> match your JSON format. Since you can detect which fields were
> present by using pointers, you can write your code to work in whatever
> way seems best for your application.

Having the json package process some explicit tag on struct members,
like, say, `json:must`, would do the trick for the OP.
Not that I need it personally, but I think I understand their wish to
not use indirection through pointers and still be able to distinguish
between an empty string and a missing value.

[alexander....@gmail.com]

This design forces us to use pointers which are less convenient. As noted by Konstantin, tag for field would be a good solution.

You say about design and I wonder for what kind of task it would be appropriate NOT to check json while unmarshalling? Where is it acceptable not to check errors? Students homework?

If we always have to check errors then we must use only pointers and there's no need completely for values.

вторник, 28 января 2014 г., 18:24:53 UTC+4 пользователь Ian Lance Taylor написал:

[Ken MacDonald]

Having the current unmarshal() behavior is very appropriate in my application. My Json represents an operation request, with up to 5 parameters. Each operation 'type' requires a 

different subset of the 5 parameters, and since this is an existing commercial application with quite a few 3rd party folks writing to it, the "unnecessary" params for an operation are rarely sent over.

With the existing system I can unmarshal the request without dealing with an error for missing Json fields. All required parameters in my case must have 'real' values - i.e. non-zero-length strings, non-zero-IDs, etc. so it

is easy to see if a valid request has been made, even if it is not "perfectly valid" Json.

The only time unmarshaling to a struct of values would be potentially unusable is when the zero-value of the data is also a valid value, i.e. if I was sending temperature data, a missing temperature value in the Json would

leave me with a "0" value in my struct, and there would be no easy way to tell if it was a valid temperature or just missing. In that case, using pointers would be appropriate.