-
Notifications
You must be signed in to change notification settings - Fork 2
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
Return more specific errors from URI validation #11
Conversation
In testing a resolver update in an app that users this library, we're getting error messages like, ``` BadUri "https://sns.us-east-1.amazonaws.com/SimpleNotificationService-60eadc530605d63b8e62a523676ef735.pem" ``` This looks entirely valid to me, but the library currently returns `BadUri` for 3 distinct validations, so breaking them up might help be realize what's going on. Hopefully.
mDomain = uriRegName <$> uriAuthority uri | ||
|
||
unless (scheme == validScheme) $ throwE $ BadScheme scheme | ||
domain <- fromMaybeM (throwE $ NoAuthority certUrlStr) mDomain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate being explicit about this and no longer just tacitly relying on the hope that ""
will not satisfy validRegPattern
| BadScheme String | ||
| NoAuthority String | ||
| BadDomain String |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might it be even better to debug if BadScheme
also included the value of validScheme
and BadDomain
included validRegPattern
to make sure these values are what you think they are?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes absolutely. In hindsight, now knowing what my bug actually was, that would've resulted in an error like,
Bad domain, aws.blah.com. Expected to match "^localhost$"
(Assuming I made a nicer displayException
.)
Which would've immediately showed me the issue.
I don't need to release this at the moment, and don't plan to. Since that's the case, I want to note it in the Unreleased section explicitly so it's noticed the next time we do a release.
In testing a resolver update in an app that uses this library, we're
getting error messages like,
This looks entirely valid to me, but the library currently returns
BadUri
for 3 distinct validations, so breaking them up might help merealize what's going on. Hopefully.