Speeding up DCD in big projects

[H. S. Teoh]

On Wed, Jul 22, 2020 at 01:28:56PM +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 2020-07-21 19:32, H. S. Teoh wrote:
> 
> > Ahh I see.  That makes sense then.
> > 
> > Which also begs the question, *why* does it even throw in the first
> > place.  The non-existence of a file is a normally-expected outcome
> > of isFile/isDir, throwing in that case seems excessively
> > heavy-handed.
> 
> If it shouldn't throw, how should it deal with other IO errors than
> non-existing file/dir? What if it exists but you don't have
> permission?

A non-existent file/dir is an expected outcome; an I/O error (e.g. disk
corruption) is not. The former should be a normal return value; the
latter should be an exception.  Similarly, if a program is testing
whether some pathname is a file, the expectation is that it has the
permission to access that path; so a permission error is likewise an
exception.


> How do you tell the difference between the following conditions when
> it only returns a bool and doesn't throw:

> * Exists and is a file // success
> * Exists and is a file but you don't have permission // error
> * Does not exist // error

I didn't say it should never throw, just that it should not throw merely
because the file doesn't exist.  The typical usage of isFile/isDir is
that if a given pathname exists and is a file/dir, then perform some
operations on it. In such scenarios, the expectation is that if the file
doesn't exist, isFile/isDir should simply return false (it doesn't
exist, so it follows logically that it's not a file/dir).

If an I/O error should occur, however, then an exception should still be
thrown (something is wrong with the filesystem, or the program doesn't
have the permissions it thought it had, which is not an expected
outcome).  The distinction between expected outcome and unexpected
outcome is important here.  You wouldn't want a function that tests
whether some number is negative to throw an exception when it's
negative, after all, since that's a normally-expected outcome. But if an
memory error was encountered when performing that test, then you *would*
want to throw an exception instead of returning true or false, because
it's an unexpected outcome, signalling that something is potentially
very wrong with the system, so normal computation should not continue.


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.