On Tue, May 21, 2013 at 11:02 PM, Matteo Landi <[email protected]> wrote: > On Mon, May 20, 2013 at 9:56 PM, Shannon Cruey > <[email protected]> wrote: >> No, it's the opposite. If the processor code catches and handles the >> exception, it would still not raise it back up to my main app, even if it >> did move on to the next processor. > > But if one of your custom application processors handles custom > exceptions to take specific actions, then there won't be any reason to > propagate the exceptions up to the application (I adapted the code you > posted previously): > > def custom_processor(handler): > try: > return handler() > except InfoException as ex: > # I use a custom HTTP status code to indicate > 'information' back to the user. > web.ctx.status = "280 Informational Response" > logger.exception(ex.__str__()) > return ex.__str__() > except SessionError as ex: > logger.exception(ex.__str__()) > # now, all our ajax calls are from jQuery, which sets > a header - X-Requested-With > # so if we have that header, it's ajax, otherwise we > can redirect to the login page. > # a session error means we kill the session > session.kill() > if web.ctx.env.get("HTTP_X_REQUESTED_WITH") == > "XMLHttpRequest": > web.ctx.status = "480 Session Error" > return ex.__str__() > else: > logger.debug("Standard Request - redirecting to > the login page...") > raise web.seeother('/static/login.html') > except Exception as ex: > # web.ctx.env.get('HTTP_X_REQUESTED_WITH') > web.ctx.status = "400 Bad Request" > logger.exception(ex.__str__()) > return ex.__str__() > > > >> >> If handle_with_processors didn't have any try block at all, then any >> exceptions would be raised to the calling app. For my use case that's fine >> but I suspect for a great many simpler use cases it might be annoying to >> require the user to write exception handler. > > If users don't use exceptions as flow control mechanism, then I expect > they won't need to catch real *exceptions* (unless they want to log a > message): an internal error sent back to the client should be enough. > > However I think here we have two problems: the first is to handle > application exceptions, the second is logging a message when an > exception is caught by the application. The former could be easily > solved using application processors, while I think the latter is > harder to fix because the framework actually lacks of a common logging > interface. > >> >> I certainly don't mind overloading. >> >> One compromise solution might be to extend handle_with_processors with an >> optional argument of whether or not to trap errors, set default to True. >> But, that doesn't seem very pythonic. >> >> I'm happy enough with what I've had to do, and will leave it up to better >> experts than me to determine how (or even if) this should result in an >> enhancement. >> >> Peace... NSC >> >> >> On Mon, May 20, 2013 at 2:13 PM, Matteo Landi <[email protected]> >> wrote: >>> >>> On Mon, May 20, 2013 at 7:11 PM, Shannon Cruey >>> <[email protected]> wrote: >>> > I fiddled with that a lot to get it right, so my memory of the process >>> > is a >>> > little hazy. Give it a try! >>> > >>> >>> I will. >>> >>> > My issue was that I needed handle_with_processors to *not* catch the >>> > exceptions at all - because I wanted to do my own error handling >>> > end-to-end >>> > by actually returning specific exception types and handling them. >>> > Handle_with_processors was hijacking the exceptions. >>> > >>> >>> If application processors were allowed to catch exceptions, would you >>> still be in need of subclassing web.Application? Probably not, you >>> could simply chain a custom processor with a custom try-catch and >>> everything should work like a charm. (Please, correct me if I am >>> wrong) >>> >>> >>> Matteo >>>
FYI here is the link to the pull request: https://github.com/webpy/webpy/pull/229 Cheers, Matteo -- You received this message because you are subscribed to the Google Groups "web.py" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/webpy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
