Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exceptions from AvisynthPluginInit3() not displayed! #315

Closed
Enyium opened this issue Jan 25, 2023 · 4 comments · Fixed by #333
Closed

Exceptions from AvisynthPluginInit3() not displayed! #315

Enyium opened this issue Jan 25, 2023 · 4 comments · Fixed by #333

Comments

@Enyium
Copy link

Enyium commented Jan 25, 2023

When env->ThrowError() is used or an AvisynthError is thrown in AvisynthPluginInit3(), there's only the message "'%s' cannot be used as a plugin for AviSynth.".

Even env->AddFunction() though, that'll always be called in AvisynthPluginInit3(), may throw "%s has an invalid parameter string (bug in filter)" (see PluginManager.cpp). It would definitely be useful to be able to read that message during development. But the way things are, this message will practically never be shown.

In my Rust crate that can be used to write plugins, I also let a plugin author return an error string from the plugin init function the same way it's possible with a plugin function (that can be called from an .avs script). Returning an error string from a plugin function gives the nice typical red error text containing the string. This should also be possible with the plugin init function. There are also errors my crate handles for the plugin author, like insufficient AviSynth+ interface version with the request to the user to update their AviSynth+ installation. So, some error strings from the plugin init function are from my crate, others can be from the plugin author.

Suggestion

When loading a plugin, please catch AvisynthErrors (besides the already existing catch (...) with literal dots) and append the thrown message as a second line or otherwise to "...cannot be used as a plugin..."

@pinterf
Copy link

pinterf commented Jan 26, 2023

This is how you imagined?

When an Avs26-style plugin throws an Avisynth exception during AvisynthPluginInit3, then I can catch the error string.

My prepared AvisynthPluginInit3 looks like:

extern "C" __declspec(dllexport)
const char* __stdcall AvisynthPluginInit3(IScriptEnvironment * env, const AVS_Linkage* const vectors)
{
 AVS_linkage = vectors;
 env->AddFunction("DoSomething", "c", Create_DoSomething, NULL);

 env->ThrowError("test throw in AvisynthPluginInit3");
 return "`Test' dummy plugin";
}

I added the exception text after the usual message:

old:
'c:/Github/Test/Debug/x64/Test.dll' cannot be used as a plugin for AviSynth

new one:

'c:/Github/Test/Debug/x64/Test.dll' cannot be used as a plugin for AviSynth. Plugin returned: test throw in AvisynthPluginInit3

@Enyium
Copy link
Author

Enyium commented Jan 26, 2023

Yes, this is what I was referring to. The line could get a bit long, though. Am I right that AviSynth avoids having anything other than a file reference with line and column in the second error message line? But anyone can violate that and use a line break in their messages anyway.

I'm not sure it would be best to have the text Plugin returned:, and then possibly the exception message from AviSynth's own AddFunction(). Maybe just leave Plugin returned: out and use a second line. It wouldn't hurt to add a code comment that points out the two kinds of messages that may be received: one originating from AviSynth itself, and a custom plugin message.

If the plugin threw something unrecognizable, the message should be identical to the present one, probably just with a period for more consistency. (Or use a generic addition, if you have an idea. But is it that it shouldn't talk about exceptions?)

@pinterf
Copy link

pinterf commented Feb 1, 2023

See commit 78c0d9f

@Enyium
Copy link
Author

Enyium commented Feb 2, 2023

What about long lines? Are you opposed to write "'%s' plugin loading error:\n%s"? Otherwise, the video may get very wide. It already contains a path at the beginning. Such an initialization failure message from the plugin author could also contain multiple lines itself. It would be strange to have the message's first line after ...plugin loading error: and the rest on their own lines.


In case of !avsexception26_message.empty(), there could be this comment:

            // Message could be from plugin author or, e.g., from env->AddFunction()

Enyium added a commit to Enyium/AviSynthPlus that referenced this issue Feb 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants