Functionality missing on Windows: should it throw or noop?

[dubiousjim]

The codebase isn't consistent about what happens when requesting functionality on Windows that isn't yet (or can't be) implemented there.

• chown -- currently throws
• chmod -- currently noop
• symlink -- currently throws
• kill(pid, signal) -- currently noop
• mkdir with non-default mode -- currently noop

Some functionality that I've pushed or have queued to push is also undecided:

• umask(mask) (Add op_umask #4290) -- currently throws
• fchmod -- queued implementation will throw
• futime -- queued implementation will throw
• fstat -- queued implementation will throw
• open with non-default mode (Add mode option to open/create #4289) -- currently noop
• truncate with non-default mode (Add mode to truncate #4288) -- currently noop
• writeFile with non-default mode -- queued implementation uses open(..., {mode:...})

What do people think we should do in these cases? Throw? or noop? I hope we can settle on a consistent pattern... though there might turn out to be corner cases where it makes sense to diverge from it.

[kitsonk]

For anything in the Deno namespace, I think it should throw. Ideally it would be a consistent error type, if we don't have it already like Deno.errors.OsUnsupported or something like that.

For things in std... I think it "depends"... Obviously for things in std/node it should behave like Node.js does. For other things, I think it really depends upon the API and the use case. Failing softly can be a good API design for some use cases.

[dubiousjim]

@ry preferred for open with non-default mode and mkdir with non-default mode to just silently ignore the mode; but made umask(mask) throw. I guess the underlying pattern is: there's something for open and mkdir still to do, they just ignore the keyword argument. Whereas umask has nothing to do on Windows in the current implementation, and would have to ignore a positional argument: umask() just returns a constant 0 on Windows.

Continuing that pattern, I'm thinking truncate should silently ignore a non-default mode, and chmod and kill should be made to throw. It's OK to leave fchmod, futime and fstat throwing.

Or do others think differently?

[bartlomieju]

Just hit this problem with kill which is silently a no-op: https://github.com/denoland/deno/pull/4397/checks?check_run_id=513464845

I'd say, that should be a hard error - it's better than silently hanging in some situation because op had no effect on Windows.

[dubiousjim]

@kitsonk, recently added to Rust there's crate::op_error::OpError::not_implemented; and we have notImplemented() in cli/js/util.ts. But that's not exported to the Deno namespace, so not available outside of cli.

[dubiousjim]

Whereas umask has nothing to do on Windows in the current implementation, and would have to ignore a positional argument: umask() just returns a constant 0 on Windows.

Slight error in what I wrote there. The version of umask that ended up in master throws on Windows regardless of whether a mask is supplied or not.

[kitsonk]

Having a Deno.notImplemented() would seem a little odd to me. Having an Deno.errrors.NotImplemented would. People don't need an exposed function to be able to throw something, do they?

[dubiousjim]

Having a Deno.notImplemented() would seem a little odd to me.

I agree

[dubiousjim]

Given recent commits, chmod and kill now throw on Windows. So now everything looks systematic:

• chown, chmod, kill, umask: all throw
• symlink: now throws, but this can be implemented later
• fchmod, futime, fstat, etc: these will throw
• supplying non-default mode to open, writeFile, truncate, mkdir: these are just ignored