Return `io::Error`s

[casey]

I noticed that which will swallow I/O errors. I think this is possibly not ideal behavior, it would be nice if which would return an I/O error, if one occurred.

[Xaeroxe]

I agree with the premise of this, surfacing more detailed errors is better. I have some questions though, which does a swarm of I/O for every request it receives. Just because an I/O error occurred doesn't mean we won't be able to fulfill the request with a subsequent read. So how would you like these non-fatal errors presented?

[Xaeroxe]

Some thoughts which come to mind are

• Add a global to the library which stores a user-provided closure. Call this closure with the I/O error whenever a non-fatal error happens.
• Update the WhichConfig type to optionally accept a user-provided closure for I/O errors
• Just log every I/O error that happens at debug! level using the tracing feature

I'd suggest modifying the return type but I'm not particularly happy with how that distorts the API shape away from the business logic purpose of the function.

[casey]

I agree with the premise of this, surfacing more detailed errors is better. I have some questions though, which does a swarm of I/O for every request it receives. Just because an I/O error occurred doesn't mean we won't be able to fulfill the request with a subsequent read. So how would you like these non-fatal errors presented?

Personally, I think I would want execution to terminate and return an io::Error after the first error. If there's an io::Error accessing a directory in the path, or a binary in a directory, then continuing might give an unexpected or unwanted result. For example, if my path has /usr/bin before /bin, and the executable is available in both places, but /usr is unmounted or unreadable, I would want to get the error instead of getting the binary in /bin, which might be incorrect if I intend /usr/bin to shadow /bin

• Add a global to the library which stores a user-provided closure. Call this closure with the I/O error whenever a non-fatal error happens.

This would make it impossible to use the library between multiple threads. Also, calling a closure means that you couldn't use ? to propagate errors, you would have to store them and check if the closure had been called.

• Update the WhichConfig type to optionally accept a user-provided closure for I/O errors

A closure would work, but you would need to manually check whether or not the closure had been called.

• Just log every I/O error that happens at debug! level using the tracing feature

I would like to handle errors, not just log them, ideally.

[Xaeroxe]

Treating non-fatal errors as fatal is a very optimistic approach and given the massive variety of environments that this code is called in we can't afford to be optimistic like that. Thanks for your feedback on the API ideas, I'll take it into account.