std/fs: Use original Error class for walk errors

[binyamin]

Related to #1310

Summary

Whenever the "walk" function encounters an error, it transforms it using the code below. In the process, it uses a generic Error class as the constructor. This means that there's no easy way to identify the type of error.

https://github.com/denoland/deno_std/blob/7afe49284d0b5357eaf0f5668080cd26f13a1d8b/fs/walk.ts#L32-L42

Proposed Solution

Use new err.constructor() instead of new Error(), when instantiating the new error class.

[lino-levan]

Could you elaborate on your use case here, I'm curious. In what situation would the error message not be good enough?

Not against this change, I think it makes sense(?) but I would appreciate further elaboration.

[binyamin]

@lino-levan Sure.

First of all, a CLI tool might want custom error messages. It also might want to add additional context to the error. For example, the filepath, or the name of a plugin.

Secondly, if the walk function receives a path which doesn't exist, it throws. But If I check first that the path exists, I seem to be introducing a race condition. But I can't handle the error easily, because it's transformed to look like a generic error. In other cases, I would use instanceof or error.name.

The only way I've found to check if it's a "Not found" error, is to parse the stack-trace. Which is not ideal, and could get complicated.

[lino-levan]

@iuioiua thoughts on this proposal? I would borderline push for a WalkError class with an err.cause defined as the error?

[lino-levan]

After some further thinking, I think I like the idea of a WalkError with a cause defined as the actual error. I will open a PR for this to further the discussion.

[kt3k]

@binyamin Does the suggested solution by @lino-levan support your use case? You can use the proposed fix from https://raw.githubusercontent.com/lino-levan/deno_std/fix-wrap-error/fs/walk.ts

import { walk } from "https://raw.githubusercontent.com/lino-levan/deno_std/fix-wrap-error/fs/walk.ts";

[binyamin]

@kt3k Yes. It would be nice if WalkError had a path property, reused from the constructor arguments. Just an idea.