Proposal: Alternative handler signature
akyoto opened this issue · 4 comments
I'd like to know what people's thoughts are on changing the aero.Handle signature from returning a string to returning an error object.
Since most people are calling ctx.HTML before returning the http body we can adjust ctx.HTML to return an error object alongside the other content types and people would have no troubles adopting the new signature. A search and replace would do the job.
The advantage is that the error return type feels more like idiomatic Go code whereas the string type forces us to do things like return "" on not-in-memory responses like ctx.File or ctx.EventStream. return nil feels a little cleaner.
Thoughts?
I have performed the changes in a separate branch, see the commit a0c5980.
We end up with quite a few code deletions and overall cleaner code. I believe this is a step in the right direction.
I think this change is great, it does look more idiomatic but as you said this change will break on the client side. Maybe it's the occasion to add two or three other breaking changes so the user have to handle these only in the next version?
I like where you're going with aerogo 😄
Normally, breaking changes can easily be handled by a major version upgrade in the semver number.
In the case of Go, however, this would cause everyone to start using "/v2" suffixed import paths in every single import which I vehemently disagree with. Import paths declare which library I'm using, not at which (major) version I am using it. Import paths should not be doing something they are not concerned with. We have a go.mod file to do versioning for us.
Using the version that is explicitly stated in the go.mod should be the default behaviour, that means no suffix should ever be required for importing the exact version that is stated in the go.mod file.
For this reason, I will have to resort to a minor version upgrade for breaking changes, even if it does not adhere to semver rules.
This is sad but I don't see another solution within the current state of Go modules.
Further discussion around this topic can be seen here:
https://groups.google.com/forum/#!msg/golang-dev/MNQwgYHMEcY/ScU6RIgICwAJ