Re: [PATCH] accept null selector for respondsTo...

[Richard Frith-Macdonald]

On Saturday, February 15, 2003, at 09:41  am, Willem Rein Oudshoorn 
wrote:

> Hm, this might be a little controversial.
> At the moment the two methods
>
>         +instancesRespondToSelector:  and -respondsToSelector:
>
> will raise an exception when passed a NULL selector.
> I prefer that it returns NO in these circumstances.
>
> First, let me confess that I do not know the behaviour on other 
> systems.
> But in as a general rule I think that querying methods like:
>
>  Is the system to be able to do XXX?
>
> Should never throw an exception.   The answer is either YES or NO.
>
> I think exceptions should be throw when during a request like:
>
>  Count number of lines in file with name "YYY"
>
> some error occur.
>
> The difference is that in the second case the error interrupts
> the normal flow of events.  While in the first case
> it does not add anything except for extra code to catch
> the potential exception.

While I more or less agree with the sentiments, the fact is that the 
current
implementation (raising an exception) is the same as that documented in
the MacOS-X release notes (which say that null pointers, particularly
selectors,  as method/function arguments should raise exception) and
observed in practice in MacOS-X

As I see it, the options are -

1. Leave it unchanged, and just say we will be McOS-X compatible.
2. Support both behaviors, with the tolerant behavior the default and 
the
exception raising behavior turned on by the existing GSMacOSXCompatible
user default.
3. Support both behaviors, making the MacOS-X behavior the default and
adding another user default to specify tolerant handling of null 
pointers
passed as method arguments.

I'm fairly happy with all options ... runtime checking of behavior 
would not be
a big overhead, since it would only be done in the unusual case when a
null pointer is detected anyway.
However, sticking with the MacOS-X behavior is obviously simplest.