-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
why HTTPError as return from HandlerFunc? #67
Comments
You can read more here http://blog.golang.org/error-handling-and-go. In short, I wanted to have a proper error type as convention instead of a generic error. The error object can still be set inside |
Isn't the blog saying exactly what I'm saying, which is to leave |
The above statement holds true in this case as well. I am not against anything it's just that I wanted returning |
Not sure what you're quoting. I guess I get to fork your repo then. What I proposed still would allow you to use HTTPError everywhere you want but doesn't force it. Too bad. |
@tve It's from the same blog post. As caller of the handlers is ServeHTTP which should only be understanding |
@vishr I think you're missing the point. From the article you are referring to:
The handlers should return |
@raphael If you look at the end of the post, the author mentions about returning appError in cases like this: type appError struct {
Error error
Message string
Code int
}
With Returning Nothing is set in stone, I am open for discussion. |
Thank you for the pointer, I understand the reference now. I guess I still don't see the benefit, it would be easy for echo to check whether the error is an |
How about if I add support for |
That would certainly help - I do wonder about how having two ways of defining handlers affects the usability of the framework though (you'd have to explain why there are two ways - when to use one vs. the other etc.). Probably something to ponder before making any change. |
Fixed in #76. |
Nice! thank you. |
Why did you make the breaking change to require HandlerFunc to return *HTTPError instead of error? Why not make HTTPError implement the Error() method and then it can be passed as error? This way a handler could either return a plain error or an HTTPError.
The text was updated successfully, but these errors were encountered: