What behavior would you expect?

[Denis McMahon]

On Fri, 20 Feb 2015 02:08:49 +1100, Chris Angelico wrote:

> On Fri, Feb 20, 2015 at 1:16 AM, Denis McMahon
> <denismfmcmahon at gmail.com>
> wrote:
>>> 2. no files match the given pattern
>>
>> Return either None, 0, False or an empty string.
>>
>> In both cases, it is then a matter for the calling code to catch the
>> exception or handle the return value appropriately.
> 
> I'd avoid the empty string here, because "absence of file" should be
> very different from "first file matching pattern". Imagine this naive
> code:

If your function documentation states that a failure to match any 
existing file returns an empty string (and if that's the case, then the 
documentation should do), then whoever calls the function should check 
the return value isn't an empty string.

There's two conflicting "paradigms" as it were here.

On the one hand, the return type of a function (when it returns, rather 
than raising an exception) should be consistent to itself, even if using 
a language where types are not declared.

On the other hand, a failure condition should clearly be a failure 
condition, which for a language that supports untyped functions means 
that we have the luxury of being able to return None / Nul[l] / NaN / 
False / 0 etc instead of a string / object / array / list / dictionary / 
mapping etc instead of raising an exception for the failure, and so we 
can try and handle the failure at the calling level without worrying 
about trapping exceptions.

I guess at the end of the day the programmer has to consider and 
determine which is most appropriate to his application, given the case.

As an aside, it's always a good idea to check that what you get looks 
like what you expected, whether it comes from a function call or as a 
data packet over the internet, before you start using it to do other 
things. ;)

-- 
Denis McMahon, denismfmcmahon at gmail.com