./README.md in sinatra-param-1.0.3 vs ./README.md in sinatra-param-1.1.0

- old
+ new

@@ -1,11 +1,11 @@ # sinatra-param _Parameter Contracts for Sinatra_ REST conventions take the guesswork out of designing and consuming web APIs. Simply `GET`, `POST`, `PATCH`, or `DELETE` resource endpoints, and you get what you'd expect. -However, when it comes to figuring out what parameters are expected... well, all bets are off. +However, when it comes to figuring out what parameters are expected... well, all bets are off. This Sinatra extension takes a first step to solving this problem on the developer side **`sinatra-param` allows you to declare, validate, and transform endpoint parameters as you would in frameworks like [ActiveModel](http://rubydoc.info/gems/activemodel/3.2.3/frames) or [DataMapper](http://datamapper.org/).** @@ -63,9 +63,38 @@ ### Defaults and Transformations Passing a `default` option will provide a default value for a parameter if none is passed. Use the `transform` option to take even more of the business logic of parameter I/O out of your code. Anything that responds to `to_proc` (including Procs and symbols) will do. + +### Exceptions + +By default, when a parameter precondition fails, `Sinatra::Param` will `halt 400` with an error message: + +```json +{ + "errors": { + "order": "Param must be within [\"ASC\", \"DESC\"]" + }, + "message": "Invalid parameter, order" +} +``` + +To change this, you can set `:raise_sinatra_param_exceptions` to `true`, and intercept `Sinatra::Param::InvalidParameterError` with a Sinatra `error do...end` block. _(To make this work in development, set `:show_exceptions` to `false`)_: + +```ruby +set :raise_sinatra_param_exceptions, true + +error Sinatra::Param::InvalidParameterError do + {error: "#{env['sinatra.error'].param} is invalid"}.to_json +end +``` + +Custom exception handling can also be enabled on an individual parameter basis, by passing the `raise` option: + +```ruby +param :order, String, in: ["ASC", "DESC"], raise: true +``` ## Contact Mattt Thompson