[patch] process_exception middleware extension

[hugo]

The attached patch includes modifications to the middleware machinery to process exceptions that might happen in a view function. This could be used for situations where some middleware needs to know wether a view function was successfully run or not. And it could be used to modify error handling in the framework.

[hugo]

process_exception extension to middleware (now with support for decorator_from_middleware)

[Adrian Holovaty]

This is an interesting hook. What would we use it for, though? We should be careful not to add hooks that we don't have a pressing need for.

[hugo]

Let's say we have a site that depends on some outside resources that might be sometimes not available. One way to do it would be explicit exception handling in the view everywhere you access that outside resource (let's just say it's a webservice and it might be sometimes down) and produce a tailored response that tells the user that a needed resource is currently unavailable and he should try again later (instead of giving a generic 500 page). With this hook a middlware could handle the exception and give a tailored error page based on the exception class.

Another situation where it would come in handy for me is when coupling the django app with outside systems - where I want to delay the commit in those outside systems to the latest possible moment, when my own viewfunc is successfully run. I would do a preparation call in the process_request phase, a committing call in the process_response hook and a backrolling call in the process_exception.

And yes, this _could_ be used for other kinds of transactions (like DB transactions), too, if one would want to hook them to the request-response mechanisms (or turned into a decorator it could be used on a per view selection).

[hugo]

Oh, just because it could be misunderstood as me trying to sneak in something from the transaction discussion from the list (heh, I would never try something like that ;-) ): at work my systems usually consist of a web app that is responsible for the user interface part - the presentation. But most actual functionality comes from backend systems like SAP or Navision ERP systems - so the situation is quite common to me that I need a global reaction to communication errors (for example some systems are connected via dialup lines and might just not be reachable at that momement). I could do that on a per-call base, but that's tedious and clumsy. I would love to be able to use a middleware there.

And the other situation - the transaction spanning - is quite common, too: if for example a shop creates an order in a system, it might need to create it not only in one system, but in multiple systems. So it would be very handy to have a layer where I could put those begin/commit/rollback calls so that external systems are in sync with my own system (the shops of course have local databases). This - again - can be done on a per-call base, but it's - again - quite clumsy. To move that stuff into a middleware would take the burdon from the actual viewfunc (the communication layers with those external apps throw dedicated exceptions that I could recognize in that middleware to know what system to rollback and what to commit).

[rjwittams]

Unless I'm mistaken, this could also be used to provide a specialised debug middleware,
that could notice certain types of exceptions and treat them differently.
The use case I'm specifically thinking of is errors thrown during template parsing, eg with
the #603 stuff enabled too, it would be possible to show the template with the offending
line highlighted.

I think it would be nice to be able to do this stuff with middleware rather than hard coding
it in as something that happens in debug mode.

[Adrian Holovaty]

(In [880]) Fixed #616 -- Added a process_exception() hook to middleware framework. Thanks, Hugo

[anonymous]

​seduction