Handle function call errors more gracefully in routes

[wxiaoguang]

Feature Description

Example: help more problems like #24118

Before

	count, err := actions_model.CountRunners(ctx, opts)
	if err != nil {
		ctx.ServerError("AdminRunners", err)
		return
	}

There are some problems:

1. The function names changes during refactoring, so the ServerError frequently gets out-of-sync.
2. People have to copy&paste duplicate code again and again.
3. The return could be forgotten, a lot of times.

Proposal 1

Use generic, let a function like ErrorProof handles server errors automatically.

ErrorProof can use reflect to get the target function's name, it doesn't affect performance because in most cases there is no "internal server error".

	count, err := ctx.ErrorProof(actions_model.CountRunners, ctx, opts))
	if err != nil {
		return
	}

Proposal 2

Return the err directly, make our handler framework support such return value for handler functions (with stacktrace):

	count, err := actions_model.CountRunners(ctx, opts)
	if err != nil {
		return ctx.ErrorWithStack(err)
	}

Feasible?

These are just some early ideas, haven't tried whether it is really feasible, but if people like this proposal, I will spend some time to try.

I really prefer the second one, it looks clear and intuitive

[silverwind]

In a sane language with exceptions, I would say throw those errors, but given golang has no exceptions besides panic/recover (I'm not sure it should those can or should be used as a rudimentary exception system), error return is probably the next best thing.

Ideally there should be linting for this but I fear it might require us to implement this linting ourselves, or maybe some existing linters can already help.

[lunny]

I like proposal 2, I have ever implemented a web framework https://gitea.com/lunny/tango support to receive one or two return error parameters like

func a() error
or
func b() (statusCode int, error)

[wxiaoguang]

I also have done similar thing in my Java/PHP/Golang web frameworks.

Usually I make the return type as an interface, then the handler could have the full control for what it wants to output.

The common responses could be provided by builtin response classes:

func handler(ctx *web.Context) Response {
    return ctx.JSON()
}

func handler(ctx *web.Context) Response {
    return ctx.HTML()
}

func handler(ctx *web.Context) Response {
    return ctx.PlainText()
}

func handler(ctx *web.Context) Response {
    return ctx.ServerError()
}

func handler(ctx *web.Context) Response {
    return &MyResponseWriter{  write status, write headers, write body ... }
}

[wolfogre]

I agree, it surprised me the first time I saw this:

	v := DoSomething(ctx)
	if ctx.Written() {
		return
	}
	// then the v is valid

[wxiaoguang]

No time for it. Close.