Repository navigation
import error is not reported #111
Description
this piece of code in importhook.cs just cleans up the import error without passing it to pythonnet:
// There was an error
if (!Exceptions.ExceptionMatches(Exceptions.ImportError)) {
// and it was NOT an ImportError; bail out here.
return IntPtr.Zero;
}
// Otherwise, just clear the it.
Exceptions.Clear();
Activity
rmadsen-ks commented on Apr 4, 2017
Clearing the ImportErrors a big problem for me because it changes the way python handles a missing module. Normally ImportErrors would be propagated up through the chain of imports. This means that I am not able to fall back to an alternative module if import raised an ImportError. Instead I have to check if the contents of the module is what I expect after loading it.
When import fails(with an ImportError), it still returns a module object, but its empty.
In the application I'm working on we allow users to define plugins by creating a module and putting it in plugins folder. We then scan the folder for plugins on runtime to determine located installed plugins. Since all ImportErrors (from regular python plugins) does not appear, I cannot give the user a proper error message when import failed. Instead I have to just write "no plugins found" when the issue was actually a mistyped import.
Maybe the exception should be saved and re-added later if it was also not a CLR module?
den-run-ai commented on Apr 4, 2017
@rmadsen-ks see a pending pull request for this:
#298
rmadsen-ks commented on Apr 5, 2017
@denfromufa, my issue is not that the error is not detailed enough, but that ImportErrors are ignored. Since ImportHook is overridden by pythonnet, this changes the way all python modules are imported not just CLR ones.
rmadsen-ks commented on Apr 5, 2017
@denfromufa, it seemed the issue was caused by me having a DLL with the same name as a python module. In normal cases, the ImportError would be emitted, but not if there is an already loaded assembly with the same name.
It seems a bit probematic because there is a good chance that someone would write a wrapper DLL with the same name as a python dll to call into python with. Not sure if different issue though.
filmor commented on Apr 5, 2017
I also had problems with this hook. I think it the long run we should replace it by an entry to sys.meta_path, that should stop it from interfering with the import mechanism.
filmor commented on Aug 6, 2021
Since the import hook is gone now, this should be fixed.