Marshalling: Exception subclasses

[james-hu]

For example, if in .NET I have this:

throw new FormatException("invalid input");

then in Node, can I know that the Error is caused by "FormatException"?

It seems this feature is missing so that the only way is to check the "message" property of the Error object?

[jasongin]

While the .NET exception message and stack trace are propagated to the JS Error, the exception type currently is not.

Would you expect a subclass of JS Error for every .NET exception type? Or perhaps a property on the error object that is the (string) type of .NET exception?

[james-hu]

Due to the weak-type nature of Javascript, and the existence of popular tools trying to minimise Javascript code size, I think having additional properties would be more robust. And I guess that is also easier to implement.

[james-hu]

But that also depends on the ambition of this project. If it is about "calling .NET from Node.js without noticing it", probably 1:1 mapping between Exception/Error types would be better. Personally I feel too good usually can't be true. Personally I am quite happy to be aware that I am writing the glue code to connect .NET and Node.js.

[luanmm]

I think that would be great if it could be a 1:1 Exception/Error in the generated code, because it would match the logic in Task/Promise and other "native" mappings.

For instance, a FormatException that inherits Exception, could generate something like this:

class FormatError extends Error {
   ...
}

That way, one could use it like this:

try {
   ...
}
catch (error) {
    if (error instanceof FormatError) { // IMHO, this is the best way to work with errors in JavaScript (seems more "strict" to language semantics, even JS being a very dynamic language)
       ...
    }
}

With custom properties, seems that the library would be using a "workaround" to allow error identification, which I don't think is a great way to do it (although it seems to be easier for now).

[jasongin]

For instance, a FormatException that inherits Exception, could generate something like this:

class FormatError extends Error {
   ...
}

Something like this should be possible (though definitely more work). Another advantage is it would allow JS to access any other properties or methods on the .NET Exception subclass, which could be very important in certain error-handling scenarios.

I'm adding this feature to the roadmap.