Deno 1.10 Extension API custom errors

[rracariu]

In Deno 1.10.1 returning an error from an Op causes an error in Deno.

thread '<unnamed>' panicked at 'Error '`my_error` err: Generic("Some error.")' contains boxed error of unknown type:
  CustomError { class: "Error", message: "`my_error` err: Generic(\"Some error.\")" }', cli\errors.rs:35:7

This is fixable by manually configuring the error resolving callback as:

fn op_name(
                state: &mut deno_core::OpState,
                args: (),
                _zero_copy: Option<deno_core::ZeroCopyBuf>,
            )
......
state.get_error_class_fn = &my_error_class_name

Expecting that the error class resolving callback should be set by default.

[AaronO]

I had explained this error to @DjDeveloperr on Discord.

This issue is due to TypeIds not being shared (and thus "stable") between deno and the extension DLL, so ref downcasting and other such operations (e.g: GothamState access) may fail.

This and #10670 will have to be fixed by a more comprehensive plugins rewrite (which I have outlined and discussed in #dev)

[rracariu]

Ouch, yeah - noticed that basically there are object duplicated in plugin and Deno, due to linking Deno core, which also exploded the size of the plugin.

I see now what is the cause, this would need to be simplified to a more C like interface that relies on some form of dynamic traits.

What I really like about the new API is that it allows exposing arguments and return types naturally to Ops (based on serde::v8) and that it takes care of the Async dispatching machinery. I hope the fixed solution will try to keep these features in some form...

[bartlomieju]

In light of plugin API removal in #11152 this issue is no longer relevant