Inappropriate use of Win32Exception

[tdinucci]

If you look at:

https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

You'll see that there are many places where Win32Exceptions are thrown and this doesn't feel right on non-Win32 platforms.

There probably is no great way to address this since moving away from Win32Exception would break existing applications. I wonder though if it'd be an improvement if a new ProcessException type was introduced which descended from Win32Exception? This way existing applications could continue to handle Win32Exceptions but developers could choose to handle ProcessExceptions when developing on non-Win32 platforms.

[stephentoub]

It's an unfortunate name, but it works cross-platform, and is really just a PlatformException with a less-than-ideal name. Changing it would be a huge breaking change, and when we previously discussed it, we decided there wasn't enough value in introducing a new exception.

[tdinucci]

The value I see here is primarily from a non-developers perspective, e.g. admins looking at logs, end users who see raw exception messages in some default exception handler, etc. Also, there'll be some value in the perception that non-Windows platforms are considered first class citizens.

I totally get that resolving this by doing something like renaming Win32Exception or creating a brand new UnixException (which didn't descend from Win32Exception would be a massive breaking change).

With my suggestion though (i.e. subclass Win32Exception) the potential to break existing code is significantly reduced (at the expensive of having a slightly confused type hierarchy). We're really talking about breaking places where types are compared explicitly, e.g.

catch(Exception ex)
{
	if(ex.GetType() == typeof(Win32Exception))
		...
}

I'd hope code like the above is rare but it would obviously break. However, I'd imagine this could be mitigated by the compiler spitting out a warning on non-Windows machines. There's obviously a question over what would happen with assemblies compiled and tested against an older version of these libraries compared to what it's actually executing on.

Anyway, I don't want to re-open a debate that's already been had. I just want to make sure that my original suggestion's been interpreted as intended.

[danmoseley]

Im inclined to agree with @tdinucci that it would make code clearer (it always catches my eye on cross platform code). We historically consider replacing an exception with a derived type as very low risk.

It wouldn't help with the HResult property though. But that's less commonly seen in cross plat code.

[jnm2]

Plus, HResult is defined on the base Exception class.

[asyncawaitmvvm]

Oh you guys.

if (string.IsNullOrEmpty(filename))
{
    throw new Win32Exception(Interop.Error.ENOENT.Info().RawErrno);
}

What exactly IS this garbage?

P.S. ENOENT = no file or directory found.

Yet under System.IO we have:

FileNotFoundException
DirectoryNotFoundException

Don't justify this source file, fix it.

[danmoseley]

@asyncawaitmvvm is catching it making your code less readable, or you just noticed this in corefx code?

Would ProcessException derived from Win32Exception be a substantial improvement for you?

[bgribaudo]

A similar idea occurred to me when working on adding dotnet/corefx#34147. Would be nice to see something like this. :-)