Comments (12)
I added a first implementation with commit 35a1f81.
from rho.
I like the feature, but would like to see if we can keep the AST clean by moving the validation to the parsers. The question arises what to do when a value parses, but fails validation? In that case I think we need a ternary representation for the return value. Something like
sealed trait ParseResult[T] {
def flatMap(... blah blah... ) ...
}
case class ParseFail(error: String) extends ParseResult[Nothing]
case class ValidationFail(error: String) extends ParseResult[Nothing]
case class Success[T](value: T) extends ParseResult[T]
from rho.
Sounds good. We should do that improvement. Than I can also solve other issues more easily.
from rho.
There are two schools of thought concerning handling error in the presence of a default.
1: On failure use the default
2: On failure fail.
Currently we are doing 1, but I like 2 better. I think returning a unknown value can result in unexpected results especially when an interface changes. I've made a branch to do that, particularly commit 1436324. The tests are not all updated to the new result, but I'll get that done soon.
Is there a show stopper with this change?
from rho.
The tests are brought into compliance with commit 7c2bbc7.
from rho.
I'm with you and prefer the 2 over 1. This makes my use cases much easier instead of working with Option
everywhere.
from rho.
I feel like this should be closed. If thats not true, feel free to reopen.
from rho.
I thought a bit about the current behavior and have the following question: Do we want to use the default value in case a number is expected but cannot be parsed? Maybe this is more handy?
from rho.
We have the following possibilities when querying for an Int
with id foo
:
/hello/world
Use the default./hello/world?foo=1
Use the result./hello/world?foo
I say use the default as no value was given./hello/world?foo=
I say this is invalid because you've passed an invalid value,""
./hello/world?foo=one
Should fail, this is an invalid query. Otherwise I would consider any result spooky.
In summary, I think we should only use the default when a value has not been presented, and never when an invalid value has been presented. The client should be alerted to their mistake so they can fix their behavior, not given a result which they may not have intended to fetch. Are there good reasons for behavior contrary to that above?
from rho.
Make sense to behave as you described it. Maybe we can improve the HTTP response by providing a better status code. A JSON-representation with a message would be nice but should be defined by the user itself.
Okay, now I have it. A user should be able to define a strategy/function in case the value is not parseable. Does it make sense?
from rho.
Yes, a failure strategy would be nice. We should make an issue for that and
start a branch.
On Jul 23, 2014 9:37 AM, "André Rouél" [email protected] wrote:
Make sense to behave as you described it. Maybe we can improve the HTTP
response by providing a better status code. A JSON-representation with a
message would be nice but should be defined by the user itself.Okay, now I have it. A user should be able to define a strategy/function
in case the value is not parseable. Does it make sense?—
Reply to this email directly or view it on GitHub
#12 (comment).
from rho.
We work in a new branch for that feature.
from rho.
Related Issues (20)
- Provide example using the Swagger UI Webjar HOT 1
- Got Error with http4s-scala-xml HOT 2
- NoSuchMethodError from rho 0.20.0-M1 HOT 2
- StringParser for value classes HOT 4
- Broken Links/URLs in `README.md` in branch `master` HOT 1
- Where is RhoService? HOT 2
- Feature Idea: Serving swagger in YAML
- Feature Idea: Customisable generic type names
- Is it possible to disable swagger.json endpoint and generate a plain json?
- Release v0.21.0 with swagger webjar implementation HOT 2
- Simple or-path produces incorrect tags HOT 1
- Getting 405 Method Not Allowed from combined routes HOT 3
- Demo example doesn't work HOT 1
- Non-class Scala types break TypeBuilder
- Logger Options in RhoRoutes
- Publish scala 3 artifacts HOT 3
- Getting 405 Method Not Allowed from combined routes with authentication
- Assembly doesn't like CollectionConverters
- Http4s, Scala, and main dependencies update HOT 3
- Maintainers wanted HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rho.