How do you mitigate against nil pointer dereference

358 views
Skip to first unread message

mail...@gmail.com

unread,
Jan 13, 2017, 8:26:12 AM1/13/17
to golang-nuts

Hello,

Have been struggling with mitigating against nil pointer deference and i would appreciate if anyone can help

Code 1:   Works file 


Code 2: Error


How do you validate Attr was set if its a pointer ? 

Thanks In Advance
Teety

mhh...@gmail.com

unread,
Jan 13, 2017, 8:41:02 AM1/13/17
to golang-nuts, mail...@gmail.com
Hi,

some simple leads,

Use one line initialization of Person
p := &Person{Attr:&Attribute{}}

Enhance the if conditions statement
    if p.Attr != nil && p.Attr.Age < 10 {
        fmt
.Println("Too Young")
   
}

Use a Person constructor
func NewPerson() &Person {
   
return &Person{Attr:&Attribute{}}
}


I, too, dislike that default values for struct pointer properties is nil.

Henrik Johansson

unread,
Jan 13, 2017, 8:44:15 AM1/13/17
to mhh...@gmail.com, golang-nuts, mail...@gmail.com

Expose properties as methods and do the check in the method can make the caller use easier.


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ian Davis

unread,
Jan 13, 2017, 9:38:45 AM1/13/17
to golan...@googlegroups.com
On Fri, 13 Jan 2017, at 10:12 AM, mail...@gmail.com wrote:

Hello,

Have been struggling with mitigating against nil pointer deference and i would appreciate if anyone can help

Code 1:   Works file 


Code 2: Error

In this case you must not ignore the error returned from json.Unmarshal. If an error is returned then p will be nil.

mail...@gmail.com

unread,
Jan 13, 2017, 12:09:44 PM1/13/17
to golang-nuts, mail...@gmail.com
Hello,

Thanks for the response. The Major Issue is that am getting the Data from json and its inconsistent.

Regards
Teety

mail...@gmail.com

unread,
Jan 13, 2017, 12:18:01 PM1/13/17
to golang-nuts

Hello,

Ignoring the error does not help 


Thank you.

mhh...@gmail.com

unread,
Jan 13, 2017, 12:27:51 PM1/13/17
to golang-nuts, mail...@gmail.com

mail...@gmail.com

unread,
Jan 13, 2017, 12:42:25 PM1/13/17
to golang-nuts, mail...@gmail.com

Can you give example how this validation can be done via such interface ? 

Ian Davis

unread,
Jan 13, 2017, 1:00:14 PM1/13/17
to golan...@googlegroups.com



On Fri, 13 Jan 2017, at 05:17 PM, mail...@gmail.com wrote:

Hello,

Ignoring the error does not help 


You changed your code by making your JSON valid so this is now a different problem to the one you originally asked.

You can take advantage of Go's ability to accept nil receivers to make your code more robust:



mhh...@gmail.com

unread,
Jan 13, 2017, 1:13:16 PM1/13/17
to golang-nuts, mail...@gmail.com
yeah, right, it s possible and works, but its way more complex, lets forget about this :)

This works https://play.golang.org/p/hP8Zq-LfQA

mail...@gmail.com

unread,
Jan 14, 2017, 6:41:17 AM1/14/17
to golang-nuts

It was easier than i expected 

mail...@gmail.com

unread,
Jan 14, 2017, 6:41:27 AM1/14/17
to golang-nuts, mail...@gmail.com
It was easier than i expected 

oelm...@leadformance.com

unread,
Jan 15, 2017, 7:55:18 PM1/15/17
to golang-nuts, mail...@gmail.com
As a side note, I'm probably stating the obvious here, but this is only a problem because your type is `*Attribute`. Should it be `Attribute` instead, your struct would be properly initialized with its fields to their zero value.

I mention it because I'm not sure myself why, from a design point of view, it's such a common practice to make pointers out of everything by default (I like the idea that what I pass as parameter can only be altered if I explicitly allow it). 

Henry

unread,
Jan 15, 2017, 8:20:14 PM1/15/17
to golang-nuts
This is why I prefer to expose my type through an interface and let others access the type variables through its methods. I just need to make sure the variables are properly initialized when accessed, and the rest of the code does not need to be littered with nil check.

Reply all
Reply to author
Forward
0 new messages