func foo() (*SomeType, error) {
...
return someErr
}
...
result, err := foo()
if err != nil {
// handle err
}
// handle result
vs type Result struct {
Err error
Data SomeType
}
func (r *Result) HasError() bool {
return r.Err != nil
}
func bar() *Result {
...
return &Result { ... }
}
...
result := bar()
if result.HasError() {
// handle result.Err
}
// handle result
I'm not really sure I see the benefit to the latter. In a language with special operators and built-in types it may be easier (e.g. foo()?.bar()?.commit()), but without these language features I don't see how the Result<T> approach is better. libraryA.Result struct {
Err error
Data SomeDataType
}
libraryB.Result struct {
err string
Data SomeDataType
}
func (r libraryB.Result) Error() string {
return r.err
}
Now you have two different implementations of the same fundamental idea, but they each require different handling. In Go, where many things simply return an error type in addition to whatever value(s), you would now have three different approaches to error handling to deal with as opposed to just whatever the language specified as the best practice.
When using older protocol versions, it can be complicated to validate that the TLS implementation you are using has the necessary mitigations in place. It can be complicated to correctly configure TLS to minimize the effects of known attacks. Doing that properly requires a fair amount of research, threat modelling, and risk assessment both for yourself and on behalf of anyone accessing your website or service.
IME, TLSv1.2 is still a big chunk of legitimate web traffic. It has been steadily dropping since standardization, and TLSv1.3 is the majority by a wide margin from what I can see. I wouldn't be surprised to see some websites and services still needing to support it for a couple years more, at least, depending on their target audience.
[1] https://tools.ietf.org/html/rfc7457
[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#Attac...