[Dancer-users] May I have some help with issue #561

[sawyer x]

This is indeed an important issue. We've been clearing off as much as we
could recently and this is definitely one of the things to focus on. Alexis
has checked this issue out this week trying to find a smooth solution for
it. Dams has written down the ground-work in which this is phase 2, in order
to fix a much bigger issue.

I hope we'll have this worked out soon enough.
We haven't forgotten this :)
and thank you for being patient!

On Tue, Jun 28, 2011 at 5:55 PM, Brian E. Lozier <brian at massassi.com> wrote:

> On Tue, Jun 28, 2011 at 7:47 AM, Brian E. Lozier <brian at massassi.com>
> wrote:
> > Issue #561 ( https://github.com/sukria/Dancer/issues/561 ) is really
> > killing me and due to the design of Dancer I can't find a simple way
> > around it.  The crux of the issue is that in Dancer::Factory::Hooks
> > all the hooks get executed and their return values aren't checked.
> > The hooks are initially compiled in Dancer::Hook and they are compiled
> > wrapped in an eval such that if an exception occurs the hook returns a
> > Dancer::halt which in turns wraps a Dancer::Response object that wraps
> > an error render.  Unfortunately nothing is ever done with this error
> > render and I don't see a standard way to actually "halt" processing.
> > If an exception occurs in a hook we should never ignore it and
> > continue processing the rest of the page!  We should die immediately
> > and print an error message to the screen.  The Dancer::halt method
> > just returns a Dancer::Response object, it doesn't actually stop
> > processing.
> >
> > As it works now, the returned Dancer::Response object is (almost)
> > completely ignored.  In fact the status code gets persisted to the
> > actual Dancer::Response that is served (500) but the page renders
> > normally otherwise.
> >
> > We are so deep in the call stack when hooks are executed that it's
> > impossible to have any meaningful "return" value (unless someone goes
> > in to every place "execute_hooks" is called and actually checks for
> > errors -- in this case it would have to check for Dancer::Response
> > objects).
> >
> > Is there a method somewhere that really halts instead of just
> > returning a Dancer::Response object?  Is there an accepted way to
> > short-circuit the rest of the request handling?
>
> According to the documentation:
>
> halt
>
> Sets a response object with the content given.
>
> When used as a return value from a filter, this breaks the execution
> flow and renders the response immediately:
>
> However, if you halt() inside a hook it does not break execution flow
> and the response is not rendered immediately. If you change my example
> above to say halt('some halt message') nothing halts. The "halt"
> function just returns a response, it doesn't break execution flow.
> Seems like this will be an easy fix if someone knows the correct way
> to break execution flow and render a Dancer::Response inside the halt
> function.
>
>
> >
> > Thanks,
> > Brian
> >
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110628/824d4ea0/attachment.htm>