While looking for the cause of Reason for panic maybe too little RAM? I came upon some things that need mending or I would like to change/optimize around ignoring.
The main issue is around how the functionality of the ignore package is exposed. Currently this is done with the exported Matcher struct and pointer methods on it. Some of these methods do check that the pointer is non-nil, others don’t. To make this consistent all exported methods can make such a check, essentially making a nil pointer a valid Matcher that matches nothing. The other option is to never check whether the pointer is nil. Thus calling a function on a nil pointer is considered a programming error and panics.
Personally I tend to not do these checks. The existence of a “constructor” (ignore.New) which returns a Matcher pointer that matches nothing seems redundant/contradictory to giving the same functionality to a nil pointer. And this doesn’t have the risk of forgetting to add the nil check when adding a new method.
@AudriusButkevicius expressed that he prefers the nil-checks and that is also (partially) what is already in place.
What are the advantages of (consistently) use such nil checks and/or problems with not having them at all?