This PR implements basic validation for begin, end, tol, and
widths.
When invalid input is encountered an exception will be thrown.
Specifically, a RuntimeException is thrown detailing the error
state that has occurred.
We debated whether or not to throw exceptions in a few cases;
ultimately we have decided that error states should be clearly
defined and handled (both for us internally and for users).
What this means is that, in a few cases, our library will throw
which results in callers being immediately alerted of the error
state that caused the exception to be thrown (so that errors are
not propagated silently throughout application code).
This is an added layer of safety to help ensure code that depends
on this library remains correct (w.r.t. it's usage of this library).
In short, the validation we are doing here says that callers:
cannot define negative image widths
cannot define invalid width ranges, e.g. begin > end
cannot define invalid width tolerance values, e.g. 0.00001
We consider these constraints to be reasonable and empowering
rather than limiting. That is, this kind of validation helps guard
against typos, e.g.
createSrcSet(String path, Map<String, String> params, int begin, int end) {...}
Will result in this exception, message, and trace:
`begin` width value must be less than `end` width value
java.lang.RuntimeException: `begin` width value must be less than `end` width value
at com.imgix.Validator.validateRange(Validator.java:49)
at com.imgix.Validator.validateMinMaxTol(Validator.java:77)
at com.imgix.URLBuilder.targetWidths(URLBuilder.java:258)
This PR implements basic validation for
begin
,end
,tol
, andwidths
.When invalid input is encountered an exception will be thrown.
Specifically, a
RuntimeException
is thrown detailing the error state that has occurred.We debated whether or not to throw exceptions in a few cases; ultimately we have decided that error states should be clearly defined and handled (both for us internally and for users).
What this means is that, in a few cases, our library will
throw
which results in callers being immediately alerted of the error state that caused the exception to be thrown (so that errors are not propagated silently throughout application code).This is an added layer of safety to help ensure code that depends on this library remains correct (w.r.t. it's usage of this library).
In short, the validation we are doing here says that callers:
begin > end
tol
erance values, e.g.0.00001
We consider these constraints to be reasonable and empowering rather than limiting. That is, this kind of validation helps guard against typos, e.g.
This call to
createSrcSet
Where the function signature is:
Will result in this exception, message, and trace: