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

make it easier to handle application error responses #34

Open
ericgj opened this issue Feb 26, 2012 · 1 comment
Open

make it easier to handle application error responses #34

ericgj opened this issue Feb 26, 2012 · 1 comment
Labels

Comments

@ericgj
Copy link
Contributor

ericgj commented Feb 26, 2012

Right now, if the request email coming in to your application isn't correct in some application-specific way, can't be parsed etc., your callback might look like

if valid?(request)
  ... 
  respond( ... )
else
  respond usage_response
end

Which is fine for simple cases, but if you have several different error conditions that each call for different behavior/responses, the code starts getting ugly with nested if's. One thing that might be helpful would be a way of exiting the callback early. You could use next -

unless valid_subject?(request)
  respond error_invalid_subject
  next
end

unless valid_body?(request)
  respond error_invalid_body
  next
end

... continue processing after validation passes

or to DRY it up, -

validate({:valid_body? => error_invalid_body,
          :valid_subject? => error_invalid_subject}) or next

... continue

But somehow that still isn't satisfying. Not suggesting rails-style controller validations, but maybe something Newman::Controller could help with that I'm not thinking of.

@practicingruby
Copy link
Contributor

How about something like this?

validate do
  # check something about the message
end

invalid_request do
  # send a response, log it, etc.
end

A failed validation would set some state (or raise an error) which causes invalid_request to be triggered. This could also be done explicitly with some method that could be called from within any matcher. Better names are needed here.

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

No branches or pull requests

2 participants