bug#60100: 29.0.60; project-current is not resilient

bug#60100: 29.0.60; project-current is not resilient

[Juri Linkov]

Is this intentional that

```
(project-current nil "/tmp/nonexistent/")
```

raises the error

  Debugger entered--Lisp error: (file-missing "Opening directory" "No such file or directory" "/tmp/nonexistent")

instead of silently returning nil.  Because when called with
an existing non-project dir, it just returns nil:

```
(project-current nil "/tmp/") => nil
```

bug#60100: 29.0.60; project-current is not resilient

[Dmitry Gutov]

On 15/12/2022 21:00, Juri Linkov wrote:
> Is this intentional that
> 
> ```
> (project-current nil "/tmp/nonexistent/")
> ```
> 
> raises the error
> 
>    Debugger entered--Lisp error: (file-missing "Opening directory" "No such file or directory" "/tmp/nonexistent")
> 
> instead of silently returning nil.

I would say this is expected.

How could we avoid this? By adding a file-exists-p check somewhere 
inside, right? And failing silently if it returns nil.

Right now the caller code needs to use that check. Or, more likely, 
figure out why they are passing in a directory that does not exist.

> Because when called with
> an existing non-project dir, it just returns nil:
> 
> ```
> (project-current nil "/tmp/") => nil
> ```

nil is a normal return value in this case: it means "no project here", 
that's a regular occasion. The callers who don't want to deal with nil 
should pass t as the first argument.

bug#60100: 29.0.60; project-current is not resilient

[Juri Linkov]

tags 60100 + notabug
close 60100 29.0.60
quit

>> Is this intentional that
>> ```
>> (project-current nil "/tmp/nonexistent/")
>> ```
>> raises the error
>>    Debugger entered--Lisp error: (file-missing "Opening directory" "No
>> such file or directory" "/tmp/nonexistent")
>> instead of silently returning nil.
>
> I would say this is expected.
>
> How could we avoid this? By adding a file-exists-p check somewhere inside,
> right? And failing silently if it returns nil.
>
> Right now the caller code needs to use that check. Or, more likely, figure
> out why they are passing in a directory that does not exist.

The problem is that callers are unaware that they need to handle this case
until they get the error that then get to use file-exists-p.  But actually
this problem is not specific to project.  Many other commands fail in such
circumstances too.  For example, 'dired-jump' raises an error on a deleted
directory as well:

  (file-missing "Setting current directory" "No such file or directory")

So now closing.