Better handling of errors during dynamic catalogue loading

[thorstenhater]

• Add platform specific handling of shared object loading
  • handle, dl_open, dl_get_symbol, dl_close
  • exceptions
  • currently POSIX only (BSD, Mac and Linux)
    • These have well-behaved const char* error messages
• All of the above may be depending on the platform, so wrap into a header util/dl.hpp and select correct platform by CPP.
  • Currently Mac and Linux are detected, everything else throws a compile error.
  • BSD should be trivial, but we cannot test.
• Refine error handling when loading catalogues
  • Test for file existence first
  • catch platform dependent errors from dl.hpp and wrap them in bad_catalogue_error

[brenthuisman]

Not sure that's true: Windows also has the concept of dynamic loading, right? I can ctypes.CDLL("my.dll") or LoadLibrary("my.dll"); on Windows.

[thorstenhater]

Yes it does. However, it does not use the POSIX/Unix way using dlopen, but rather the Win32 LoadLibrary. So, the compiler error is the prompt for us implement the API outlined in dl_platform_posix.hpp when the time should come to port to Windows. Same story for BSD: Once we compile there, we need to test dl_platform_posix.hpp against that OS, add an ifdef, and move on. But as long as we do not regularly test on those platforms, I would rather not enable them.

The error message should probably say "No platform support for dynamic loading found" though

[brenthuisman]

Might need to namespace the expected error: arbor._arbor.FileNotFoundError.

[thorstenhater]

Might need to namespace the expected error: arbor._arbor.FileNotFoundError.

Issue is the semantics of register_exception. It will create a new Py Exception in the module.
We need however the global one.

Update: Fix is to use register_exception("Name", PyC_FileNotFoundError), making Name but inheriting from FNFE.
Working in CI right now.

[brenthuisman]

lgtm!

[noraabiakar]

Looks great thanks! I have a few questions about that code and the possible problems we can run in to.