dry-types source code, I have been very surprised to see that
params coercions rescue from
TypeError and, for dates and times,
RangeError exceptions, passing through everything they don’t know how to coerce.
I guess that the rationale behind it is that
json are user provided input, so they can be anything and we should let the application deal with what to do. But I have some objections:
- It is true that
paramsare always user provided input, but it is not the case for
json, which, for example, could be some automatically generated output data from a datastore.
- It leads to extremely unsafe code in two ways:
- It doesn’t do any parameter sanitation at all.
- It gives you with a value that can effectively be anything, so you have to ask what it is in the style of
#is_a?(String). I would expect
dry-typesto give me some type safety in this regard.
In my case I’m working with params and I would like to let the application crash if the user gives me something I don’t expect, because it is a sign that he is trying to tamper in some way. However, I still see the benefit in letting the application deal with such errors. For this reason, I think that a better approach would be to be safe by default but still let the application a way to deal with the errors wrapping the argument, type or range error in a custom
dry-types exception with some fields like the value given and the coercion that was tried to be performed.
What do you think?