🙏🏻[feat/req] Need more details in error messages for thrown errors

[rivy]

I just ran into this error while using fs::walk()...

...
error: Uncaught NotFound: The system cannot find the path specified. (os error 3)
  for (const entry of Deno.readDirSync(root)) {
                           ^
    at unwrapOpResult (deno:core/core.js:100:13)
    at Object.opSync (deno:core/core.js:114:12)
    at Object.readDirSync (deno:runtime/js/30_fs.js:105:17)
    at walkSync (https://deno.land/std@0.92.0/fs/walk.ts:160:28)
    at walkSync.next (<anonymous>)
    at walkSync (https://deno.land/std@0.92.0/fs/walk.ts:177:14)
    at walkSync.next (<anonymous>)
    at walkSync (https://deno.land/std@0.92.0/fs/walk.ts:177:14)
    at walkSync.next (<anonymous>)
    at walkSync (https://deno.land/std@0.92.0/fs/walk.ts:177:14)
...

After some sleuthing, it turns out one of the sub-directories in the walk has disabled read permissions. But that's really impossible to determine from the information within the error object. Just adding the attempted path to the error would be have made debugging this significantly easier.

A lot of errors seem to be a blandly generic and, with an added bit more contextual information, could be of significantly more benefit to devs.

[bnoordhuis]

I don't think Deno has access to more information than you do. That NotFound error bubbles up from the operating system, Deno just passes it on to you.

[rivy]

I don't think Deno has access to more information than you do. That NotFound error bubbles up from the operating system, Deno just passes it on to you.

If this was caught and re-thrown, the value of root sent to readDirSync() could be added to the exception which would be very helpful tracking down basis of the problem at issue.

[nayeemrmn]

I think it's standard to just carry forward the OS error where applicable, the user should do that. However in this case the "user" with access to that is std -- walk() should probably indicate what path it hits an error on. This is an std issue.