Needlessly Safe Code

[Verde]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the "real
work" it could be doing, but would like to instead focus our attention on
the [extensive checking] vs [zero checking] implemented in these two
methods.

Safe code that makes few assumptions about its runtime conditions is good,
but what about "needlessly safe"?

Is Version 1 below "needlessly safe" in your opinion?

------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory was not
found.");
}
}

------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"... open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for file/directory
existance
}

Please note that my question isn't about working with files. The code above
just serves to provide an example of "safe coding" vs code that makes
assumptions.

Thanks in advance!

 

[mgsram]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the "real
work" it could be doing, but would like to instead focus our attention on
the [extensive checking] vs [zero checking] implemented in these two
methods.

Safe code that makes few assumptions about its runtime conditions is good,
but what about "needlessly safe"?

Is Version 1 below "needlessly safe" in your opinion?

------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory was not
found.");
}

}

------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"... open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for file/directory
existance

}

Please note that my question isn't about working with files. The code above
just serves to provide an example of "safe coding" vs code that makes
assumptions.

Thanks in advance!

Looking at your example, I dont think Version#1 is any more safer than
Version#2. They are both doing the same thing; Version #1 has
redundant code and does not add any additional value than Version #2.
In a broader sense the question is whether to be proactive or
reactive. I think it varies from case to case. For e.g. if i have to
convert 1000 strings to double in a loop and if the 1000 strings are
from a random file, I would prefer using Double.TryParse() to check if
it is a valid double and then parse it. If it were something like the
above example, I would catch the exception.

 

[Jeroen Mostert]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the "real
work" it could be doing, but would like to instead focus our attention on
the [extensive checking] vs [zero checking] implemented in these two
methods.

Safe code that makes few assumptions about its runtime conditions is good,
but what about "needlessly safe"?

There's no such thing. I could go for "pointlessly safe" and "apparently
safe", though.

Is Version 1 below "needlessly safe" in your opinion?

------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...

Whoops, exception: another process deleted the file after you checked for
its existence. What now?

The only purpose such checks could serve is to alert the user to problems
before you even attempt the operation. They cannot give any guarantee that
the operations will succeed.

}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}

This is doubly pointless: you check for the file's existence, and when it's
not there... you throw an exception. Just like any method that operates on
the file would do. You've gained nothing.

------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"... open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for file/directory
existance
}

The question is whether you *can* do anything with an error condition. If
DoSomethingWithAFile() cannot do anything meaningful if the file does not
exist, it only has to make sure it doesn't do anything *else* when the file
does not exist (that is, no unintended side effects), and propagating
exceptions is the right and proper thing to do in this case.

Ironically, you missed the only truly meaningful check in both versions:

if (pathToTheFile == null) throw new ArgumentNullException("pathToTheFile");

Please note that my question isn't about working with files. The code above
just serves to provide an example of "safe coding" vs code that makes
assumptions.

To paraphrase Saint-Exupéry: safety is not achieved when there is nothing
left to check, but when there is nothing left to cause an unrecoverable error.

Error handling is not peppering your code with checks, it's identifying the
points in your code where errors need to be handled in order to recover
meaningfully or fail gracefully. Exceptions give you the advantage that an
error cannot go unhandled; what's left is devising effective ways to handle
them.

 

[henk holterman]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the "real
work" it could be doing, but would like to instead focus our attention on
the [extensive checking] vs [zero checking] implemented in these two
methods.
[...]

Verde, if I take your example literally there is no difference at all
(except maybe the exact text in the strings). But if the else branches
contained anything else than a throw it would be an entirely different
matter.

Please note that version #1 uses the same strategy as #2 when it comes
to, for example, insufficient rights for the file. Or the unlikely
scenario in which the file is deleted between the Exists check and the
Open.

So for those reasons I would prefer version #1, and maybe put in a
comment like "error checking by the FileStream class"

-HH-

 

[parez]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the "real
work" it could be doing, but would like to instead focus our attention on
the [extensive checking] vs [zero checking] implemented in these two
methods.

Safe code that makes few assumptions about its runtime conditions is good,
but what about "needlessly safe"?

Is Version 1 below "needlessly safe" in your opinion?

------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory was not
found.");
}

}

------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"... open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for file/directory
existance

}

Please note that my question isn't about working with files. The code above
just serves to provide an example of "safe coding" vs code that makes
assumptions.

Thanks in advance!

I *THINK* exceptions cause overhead so its better to do the checks..

 

[parez]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the "real
work" it could be doing, but would like to instead focus our attention on
the [extensive checking] vs [zero checking] implemented in these two
methods.

Safe code that makes few assumptions about its runtime conditions is good,
but what about "needlessly safe"?

Is Version 1 below "needlessly safe" in your opinion?

------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory was not
found.");
}

------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"... open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for file/directory
existance

Please note that my question isn't about working with files. The code above
just serves to provide an example of "safe coding" vs code that makes
assumptions.

Thanks in advance!

I *THINK* exceptions cause overhead so its better to do the checks..

I think i thought right..
private void FileTest1(string file)
{

try
{
FileStream fs = File.Open(file, FileMode.Open);
}
catch (Exception)
{
}
}
private void FileTest2(string file)
{

try
{
if (!File.Exists(file))
throw new FileNotFoundException("file not found",
file);
}
catch (Exception)
{
}
}

private void RunFileTest()
{

int times = 5000;

string file="C:\\some.txt";

Stopwatch sw1 = new Stopwatch();

sw1.Start();
for (int i = 0; i < times; i++)
{
FileTest1(file);
}
sw1.Stop();

Stopwatch sw2 = new Stopwatch();

sw2.Start();
for (int i = 0; i < times; i++)
{
FileTest2(file);
}
sw2.Stop();


// MessageBox.Show(string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds));
label6.Text = string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds);
}

Output
label6.Text "Test1 Result 27.383811 \nTest2 Result 25.5081203"
string

 

[cfps.Christian]

Throwing/Catching is EXTREMELY costly. Do the checks, but if you're
on a timetable there is a limit to the amount of validation you can do
before you just need to put in the try/catch block and call it done.
I know we use try/catch on every entry point (user event) since those
will cause the app to explode.

 

[Willy Denoyette [MVP]]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the
"real
work" it could be doing, but would like to instead focus our attention on
the [extensive checking] vs [zero checking] implemented in these two
methods.

Safe code that makes few assumptions about its runtime conditions is
good,
but what about "needlessly safe"?

Is Version 1 below "needlessly safe" in your opinion?

------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory was
not
found.");
}

}

------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"...
open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for file/directory
existance

}

Please note that my question isn't about working with files. The code
above
just serves to provide an example of "safe coding" vs code that makes
assumptions.

Thanks in advance!

I *THINK* exceptions cause overhead so its better to do the checks..

Doing the test makes absolutely no sense (please read Jeroen's answer),
there is no guarantee whatsoever that you will be able to open the file
after the test, the file may no longer exist, or may not be accessible due
to security or sharability constraints.

Willy.

 

[Willy Denoyette [MVP]]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the
"real
work" it could be doing, but would like to instead focus our attention
on
the [extensive checking] vs [zero checking] implemented in these two
methods.

Safe code that makes few assumptions about its runtime conditions is
good,
but what about "needlessly safe"?

Is Version 1 below "needlessly safe" in your opinion?

------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory was
not
found.");
}

------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"...
open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for
file/directory
existance

Please note that my question isn't about working with files. The code
above
just serves to provide an example of "safe coding" vs code that makes
assumptions.

Thanks in advance!

I *THINK* exceptions cause overhead so its better to do the checks..

I think i thought right..
private void FileTest1(string file)
{

try
{
FileStream fs = File.Open(file, FileMode.Open);
}
catch (Exception)
{
}
}
private void FileTest2(string file)
{

try
{
if (!File.Exists(file))
throw new FileNotFoundException("file not found",
file);
}
catch (Exception)
{
}
}

private void RunFileTest()
{

int times = 5000;

string file="C:\\some.txt";

Stopwatch sw1 = new Stopwatch();

sw1.Start();
for (int i = 0; i < times; i++)
{
FileTest1(file);
}
sw1.Stop();

Stopwatch sw2 = new Stopwatch();

sw2.Start();
for (int i = 0; i < times; i++)
{
FileTest2(file);
}
sw2.Stop();


// MessageBox.Show(string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds));
label6.Text = string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds);
}

Output
label6.Text "Test1 Result 27.383811 \nTest2 Result 25.5081203"
string

25 seconds to test 500 times if a file exists? This seems like impossible,
it should be less than a second even on the slowest system.

Willy.

 

[Willy Denoyette [MVP]]

I would appreciate your comments on the following two alternatives of
a
given method. This isn't a real method, as I'm not concerned about the
"real
work" it could be doing, but would like to instead focus our attention
on
the [extensive checking] vs [zero checking] implemented in these two
methods.

Safe code that makes few assumptions about its runtime conditions is
good,
but what about "needlessly safe"?

Is Version 1 below "needlessly safe" in your opinion?

------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory
was not
found.");
}

}

------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the
bat"... open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for
file/directory
existance

}

Please note that my question isn't about working with files. The code
above
just serves to provide an example of "safe coding" vs code that makes
assumptions.

Thanks in advance!

I *THINK* exceptions cause overhead so its better to do the checks..

I think i thought right..
private void FileTest1(string file)
{

try
{
FileStream fs = File.Open(file, FileMode.Open);
}
catch (Exception)
{
}
}
private void FileTest2(string file)
{

try
{
if (!File.Exists(file))
throw new FileNotFoundException("file not found",
file);
}
catch (Exception)
{
}
}

private void RunFileTest()
{

int times = 5000;

string file="C:\\some.txt";

Stopwatch sw1 = new Stopwatch();

sw1.Start();
for (int i = 0; i < times; i++)
{
FileTest1(file);
}
sw1.Stop();

Stopwatch sw2 = new Stopwatch();

sw2.Start();
for (int i = 0; i < times; i++)
{
FileTest2(file);
}
sw2.Stop();


// MessageBox.Show(string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds));
label6.Text = string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds);
}

Output
label6.Text "Test1 Result 27.383811 \nTest2 Result 25.5081203"
string

25 seconds to test 500 times if a file exists? This seems like impossible,
it should be less than a second even on the slowest system.

Willy.

Sure, I mean 5000 times .....

Willy.

 

[mgsram]

Throwing/Catching is EXTREMELY costly. Do the checks, but if you're
on a timetable there is a limit to the amount of validation you can do
before you just need to put in the try/catch block and call it done.
I know we use try/catch on every entry point (user event) since those
will cause the app to explode.

1) The comparison of failures is insufficient. You should also compare
the happy path.
2) Its a trade off. For processing 5000 files, the above approach is
suitable. For a handful of files, the performance overhead of failure
scenarios is negligible. In fact not having the check would improve
the happy path performance.
3) I fully agree with Jereon's post above. Your example still does not
show a valid recovery and hence the check is useless as if the file
got deleted just after File.Exists returned true, you will still get
an exception.

 

[parez]

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the
"real
work" it could be doing, but would like to instead focus our attention
on
the [extensive checking] vs [zero checking] implemented in these two
methods.
Safe code that makes few assumptions about its runtime conditions is
good,
but what about "needlessly safe"?
Is Version 1 below "needlessly safe" in your opinion?
------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory was
not
found.");
}
}
------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"...
open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for
file/directory
existance
}
Please note that my question isn't about working with files. The code
above
just serves to provide an example of "safe coding" vs code that makes
assumptions.
Thanks in advance!
I *THINK* exceptions cause overhead so its better to do the checks..

I think i thought right..
private void FileTest1(string file)
{

try
{
FileStream fs = File.Open(file, FileMode.Open);
}
catch (Exception)
{
}
}
private void FileTest2(string file)
{

try
{
if (!File.Exists(file))
throw new FileNotFoundException("file not found",
file);
}
catch (Exception)
{
}
}

private void RunFileTest()
{

int times = 5000;

string file="C:\\some.txt";

Stopwatch sw1 = new Stopwatch();

sw1.Start();
for (int i = 0; i < times; i++)
{
FileTest1(file);
}
sw1.Stop();

Stopwatch sw2 = new Stopwatch();

sw2.Start();
for (int i = 0; i < times; i++)
{
FileTest2(file);
}
sw2.Stop();

// MessageBox.Show(string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds));
label6.Text = string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds);
}

Output
label6.Text "Test1 Result 27.383811 \nTest2 Result 25.5081203"
string

25 seconds to test 500 times if a file exists? This seems like impossible,
it should be less than a second even on the slowest system.

Willy.

hehe.. I was changing the numbers around... i pasted wrong code..
anyways it is 5000
"Test1 Result 27.7139862 \nTest2 Result 25.6947071"



I must have changed the number...

 

[parez]

news:[email protected]...

I would appreciate your comments on the following two alternatives of a
given method. This isn't a real method, as I'm not concerned about the
"real
work" it could be doing, but would like to instead focus our attention
on
the [extensive checking] vs [zero checking] implemented in these two
methods.
Safe code that makes few assumptions about its runtime conditions is
good,
but what about "needlessly safe"?
Is Version 1 below "needlessly safe" in your opinion?
------------------------------------------------
Version 1 - Extensive "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
if (Directory.Exists(Path.GetDirectoryName(pathToTheFile)))
{
if (File.Exists(pathToTheFile))
{
// Do something with the file here... open it, whatever...
}
else
{
throw new System.IO.FileNotFoundException("The file was not
found.");
}
}
else
{
throw new System.IO.DirectoryNotFoundException("The directory was
not
found.");
}
}
------------------------------------------------
Version 2 - No "runtime environment" Checking
------------------------------------------------
public void DoSomethingWithAFile(string pathToTheFile)
{
// Just try to something with the file here - right "off the bat"...
open
it, whatever...
// If it cannot be located, then system.IO will throw an exception
// ... therefore I don't need to do all the checking for
file/directory
existance
}
Please note that my question isn't about working with files. The code
above
just serves to provide an example of "safe coding" vs code that makes
assumptions.
Thanks in advance!
I *THINK* exceptions cause overhead so its better to do the checks..
I think i thought right..
private void FileTest1(string file)
{
try
{
FileStream fs = File.Open(file, FileMode.Open);
}
catch (Exception)
{
}
}
private void FileTest2(string file)
{
try
{
if (!File.Exists(file))
throw new FileNotFoundException("file not found",
file);
}
catch (Exception)
{
}
}
private void RunFileTest()
{
int times = 5000;
string file="C:\\some.txt";
Stopwatch sw1 = new Stopwatch();
sw1.Start();
for (int i = 0; i < times; i++)
{
FileTest1(file);
}
sw1.Stop();
Stopwatch sw2 = new Stopwatch();
sw2.Start();
for (int i = 0; i < times; i++)
{
FileTest2(file);
}
sw2.Stop();
// MessageBox.Show(string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds));
label6.Text = string.Format("Test1 Result {0} \nTest2
Result {1}", sw1.Elapsed.TotalSeconds, sw2.Elapsed.TotalSeconds);
}
Output
label6.Text "Test1 Result 27.383811 \nTest2 Result 25.5081203"
string

25 seconds to test 500 times if a file exists? This seems like impossible,
it should be less than a second even on the slowest system.

Willy.

hehe.. I was changing the numbers around... i pasted wrong code..
anyways it is 5000
"Test1 Result 27.7139862 \nTest2 Result 25.6947071"

I must have changed the number...

its not the check..
its the

if (!File.Exists(file))

 

[Jeff Louie]

Verde...The first example uses the TESTER-DOER idiom. On a multi user,
multi
threaded, multi tasking system, the safe idiom is to catch the exception
if the
file does not exist or is locked.

Regards,
Jeff

 

[Ben Voigt [C++ MVP]]

Now, this is specific to interacting with the file system. That's a

bit of a specific example, because your program has no control over
the state of the file system. That's why things can change between
statements in your own code. In a different situation, in which the

Well, I think you've just explained why it applies to any namespace shared
asynchronously, not just the filesystem.

 

[Ben Voigt [C++ MVP]]

I don't fully understand your use of "namespace" here, but yes...I
didn't mean to say that this sort of reasoning applies _only_ to the
filesystem. Just that the example, using the filesystem, is subject
to the reasoning.

"namespace" is the term used for filenames, PIDLs, device names, URIs, etc
"address space" for pointers

I agree, the same sort of concerns would apply to any resources that
are not completely under the control of the application.

I suppose for that matter it also applies to asynchronous resources
that are completely under the control of the application but which
are used in an unsynchronized way. But IMHO that's just plain buggy
code.

Something has got to be used asynchronously.

But here, think of the double-checked locking (anti-)pattern... it's almost
exactly the same as the case in question (and in that pattern as well, the
first check can return a wrong result).