{"action":"created","issue":{"url":"https://api.github.com/repos/funcool/buddy-sign/issues/38","repository_url":"https://api.github.com/repos/funcool/buddy-sign","labels_url":"https://api.github.com/repos/funcool/buddy-sign/issues/38/labels{/name}","comments_url":"https://api.github.com/repos/funcool/buddy-sign/issues/38/comments","events_url":"https://api.github.com/repos/funcool/buddy-sign/issues/38/events","html_url":"https://github.com/funcool/buddy-sign/issues/38","id":167075729,"number":38,"title":"Don't throw exception if 'unsign' fails, just return data","user":{"login":"laczoka","id":185360,"avatar_url":"https://avatars.githubusercontent.com/u/185360?v=3","gravatar_id":"","url":"https://api.github.com/users/laczoka","html_url":"https://github.com/laczoka","followers_url":"https://api.github.com/users/laczoka/followers","following_url":"https://api.github.com/users/laczoka/following{/other_user}","gists_url":"https://api.github.com/users/laczoka/gists{/gist_id}","starred_url":"https://api.github.com/users/laczoka/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/laczoka/subscriptions","organizations_url":"https://api.github.com/users/laczoka/orgs","repos_url":"https://api.github.com/users/laczoka/repos","events_url":"https://api.github.com/users/laczoka/events{/privacy}","received_events_url":"https://api.github.com/users/laczoka/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-07-22T15:50:28Z","updated_at":"2016-07-25T17:34:55Z","closed_at":null,"body":"This is more of a feedback on the public API.\r\nWe quite like this little library and the fact that it has minimal dependencies.\r\n\r\nHowever, using exceptions to report expected errors is an anti-pattern.  There is simply no need to do this. Let the client code decide if they want to throw an exception on unsuccessful 'unsign', most of the time they wil not, they will just pick an alternative code path.\r\n\r\nAt this point, you may not want to break the public API, but providing alternative methods that return errors as data would be highly appreciated.\r\n\r\nThanks"},"comment":{"url":"https://api.github.com/repos/funcool/buddy-sign/issues/comments/235024798","html_url":"https://github.com/funcool/buddy-sign/issues/38#issuecomment-235024798","issue_url":"https://api.github.com/repos/funcool/buddy-sign/issues/38","id":235024798,"user":{"login":"niwinz","id":843689,"avatar_url":"https://avatars.githubusercontent.com/u/843689?v=3","gravatar_id":"","url":"https://api.github.com/users/niwinz","html_url":"https://github.com/niwinz","followers_url":"https://api.github.com/users/niwinz/followers","following_url":"https://api.github.com/users/niwinz/following{/other_user}","gists_url":"https://api.github.com/users/niwinz/gists{/gist_id}","starred_url":"https://api.github.com/users/niwinz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/niwinz/subscriptions","organizations_url":"https://api.github.com/users/niwinz/orgs","repos_url":"https://api.github.com/users/niwinz/repos","events_url":"https://api.github.com/users/niwinz/events{/privacy}","received_events_url":"https://api.github.com/users/niwinz/received_events","type":"User","site_admin":false},"created_at":"2016-07-25T17:34:55Z","updated_at":"2016-07-25T17:34:55Z","body":"I mostly agree with your arguments. But I'm not clearly understand some parts.\r\n\r\nAre you suggesting return the same result in successful and unsuccessful validation of the token?\r\nIn this case, this seems like a bad idea because it is completely counterintuitive and not evident.\r\n\r\nAlso, unfortunately to our opinion about exceptions, they seems like the most used way to handle this kind of stuff in the clojure ecosystem and this is the reason of using them as default approach.\r\n\r\nIn order to expose additional api that return errors as values, a proper way to signal the validation error should be choiced. Returning the same value for success and validation error is not an option. As I said previously is very confusing and not evident to the final user. Additionally, not all validation errors can return the data (on JWE as example valid tokens but encrypted with different key, will cause a validation error but the data can't be retrieved).\r\n\r\nOn the end, I don't know that abstraction is better for create the new functions that return validation errors as value. I think that vector of `[result, error]` is the proper approach for it, but I'm not pretty sure..."}}
{"actor":{"display_login":"niwinz"}}