Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exceptions in #before block are not caught by error handler #812

Closed
Wardrop opened this issue Mar 27, 2012 · 5 comments
Closed

Exceptions in #before block are not caught by error handler #812

Wardrop opened this issue Mar 27, 2012 · 5 comments
Milestone

Comments

@Wardrop
Copy link

Wardrop commented Mar 27, 2012

I've noticed in Padrino 0.10.5 that exceptions raised from a #before block do not invoke the user-defined error handlers, e.g.

before do
  raise StandardError, "Something went wrong"
end

error do
  "Sorry, but your request could not be fulfilled"
end

I attempted to upgrade to 0.10.6 to see if the problem still exists, however my application completely broke, that's a separate issue though, so I'll have to assume the behavior is unchanged in 0.10.6 unless someone can prove otherwise.

@nesquena
Copy link
Member

can you elaborate on 'my app completely broke'. Are you using pry?

@Wardrop
Copy link
Author

Wardrop commented Mar 27, 2012

My configure blocks were being executed before any of dependencies (models, library file) were loaded. 0.10.5 loaded everything before the configure blocks were run, after all the whole point of a configure block is to configure the application environment which includes application dependencies.

Anyway I'm more concerned about the issue with before block errors not being caught. Something else I've noticed is that if a route raises an exception, before blocks are called again. So they're called once at the start of the request, and then called again whenever an error occurs. This may be part of the same issue as this doesn't seem like the intended behavior.

@nesquena
Copy link
Member

OK thanks for the report. We will investigate soon.

@ujifgc
Copy link
Member

ujifgc commented Jan 10, 2013

The second part of the issue is related to #818

@ujifgc
Copy link
Member

ujifgc commented Jan 10, 2013

@Wardrop the error do part should be error 500 do in your code to customize StandardError or other common exceptions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants