don’t intercept exceptions in AtomicShortcode and BlockShortcode about shortcodes

[dmulholl]

Hi Konrad. Thanks for filing such a detailed and helpful report.

The rationale for wrapping rendering-callback exceptions is so we can guarantee that the library will only ever throw a ShortcodeError exception (or one of its subclasses). This is a useful feature if the code is going to be running unattended on a server.

You're absolutely right that it's important to preserve the original exception, but Python 3 actually does this automatically. If you raise a new exception from within an except block then the original exception is preserved as the new exception's __context__ attribute.

This is pretty obscure behaviour so I'm going to add notes to the code and documentation to make it clear that it's happening.

Also, looking again at the docs and the original PEP, I think we should probably be using the explicit __cause__ attribute as well as relying on __context__ being set automatically.

I can add this without compromising backwards compatibility so I'll push an update tonight or tomorrow.

I think looking at __context__ or __cause__ should solve your problem but I'm not familiar with how Django middleware operates so let me know if there's still an issue.

[kmohrf]

i guess you’re suggesting to use the new raise … from … syntax?
but it’s good to know that raise sets the context of the new exception to the one that was catched. i didn’t know that.

as far as i’m concerned that’s everything i need as i have control over the middleware and can just catch the RenderingError and use the __context__, though there might still be a use case for configuring the behaviour.

thank you for taking the time!

[dmulholl]

I just pushed version 2.4.0 which uses the raise ... from ... syntax to explicitly wrap handler exceptions. Thanks for bringing up the issue - I think it's much clearer now what's actually happening in the code.