CC @neild @bradfitz

We aren't making breaking changes to the standard library, so this is moot.

That said, I'm extremely dubious about the value of doing this. If two pieces of code attempt to register the same path, your choices largely come down to not starting the program, or picking a winner. Picking a winner is a poor choice; there's a fault in the program logic and we have no way to tell how serious it is. It isn't difficult to construct scenarios where papering over the error causes a significant outage or security vulnerability.

Panicking immediately surfaces the issue in a clear fashion, generally at program start time.

If panics are a problem due to too many sources registering handlers on DefaultServeMux, I don't see how returning an error helps: Instead of a panic, you either get effectively random behavior over which handler is registered, or something looks at the error and panics anyway.

Returning an error would be an opportunity to handle it in an orderly fashion. For instance, a framework could take that error and export it to a monitoring system.

In fact, the most common way I have seen this happen is in a test:

func TestA(t *testing.T) {
  http.Handle("/", &MyHandler{})
  // run test
}

func TestB(t *testing.T) {
  http.Handle("/", &SomeOtherHandler{})  // panic
  // run test
}

We have users that test that their initialization routine works, but as soon as there is a HTTP handler registration, the routine can no longer be idempotent.

Tests should be using a test-specific mux, not the global DefaultServeMux. Panicking in this case seems better than returning an error that the test might ignore.

I'm not supportive of this proposal, for reasons that have already been enumerated already.

However, I see an opportunity for improving the panic message.

Auditing no. 2 was a boil-the-ocean affair, particularly because there was no wisdom nor enforcement of avoiding mutating package state in registrations.

The http panic message could be improved so that it reads something like:

http: multiple registrations for /path. conflicting handlers are:
   logingHandler - /home/main.go:312
   shoppingCartHandler - /home/shop.go:17

The exact message can be up to debate, but the general idea is that the panic will tell you exactly where the conflicting handlers are defined.

This is similar to the superfluous response.WriteHeader call where the http library provides this sort of info:

I know that in the case of superfluous it is a log message instead of a panic message. But still debugging superfluous is much easier than debugging multiple registrations and the callers info makes it that easy.

2 cents.

I like the idea of annotating the panic message with extra line numbers. We do something similar with an internal config library extracting values from the environment, where we want to guarantee (for maintainability) that only one code location ever looks at any given variable.

Returning an error would be an opportunity to handle it in an orderly fashion. For instance, a framework could take that error and export it to a monitoring system.

AFAIK Handle{,Func} only ever panics on duplicate registration (correct me if I'm wrong) so ISTM this would work

func FrameworksHandle(pattern string, h http.Handler) (err error) {
    defer func() {
        if recover() != nil {
            err = fmt.Errorf("duplicate registration of %q", pattern)
        }
    }()
    http.Handle(pattern, h)
}

Personally, I tend to agree with @neild though, there doesn't seem to really be anything useful to do with that error, in general.