In the sync implementation, we make a statSync call, and if it fails, the original mkdirSync error is thrown:
|
try { |
|
if (!options.fs.statSync(pth).isDirectory()) { |
|
throw new Error('The path is not a directory'); |
|
} |
|
} catch (_) { |
|
throw error; |
|
} |
However, in the async implementation, we have no error handling for the stat call, and any failure there would bubble up:
|
const stats = await stat(pth); |
|
if (!stats.isDirectory()) { |
|
throw error; |
|
} |
In an earlier (pre-async/await) version, we properly swallowed any stat errors, and threw the original error, like the sync implementation:
|
return stat(pth) |
|
.then(stats => stats.isDirectory() ? pth : Promise.reject()) |
|
.catch(() => { |
|
throw error; |
|
}); |
I don't have a test case to show if this actually creates an inconsistency for the end user, but it was just noticed in review, and I thought I'd report upstream.
In the sync implementation, we make a
statSynccall, and if it fails, the originalmkdirSyncerror is thrown:make-dir/index.js
Lines 137 to 143 in 9de6474
However, in the async implementation, we have no error handling for the
statcall, and any failure there would bubble up:make-dir/index.js
Lines 84 to 87 in 9de6474
In an earlier (pre-async/await) version, we properly swallowed any
staterrors, and threw the original error, like the sync implementation:make-dir/index.js
Lines 76 to 80 in 379001f
I don't have a test case to show if this actually creates an inconsistency for the end user, but it was just noticed in review, and I thought I'd report upstream.