Remix.run Logo
raverbashing 5 days ago

It's like an inverted game of cat and mice

1 - Lang/OS/Lib developer puts out a quirky or buggy API (or even just an ok API)

2 - Developers rely on a quirky, weird or unexpected side effect because it's easier/more obvious or it just works this way due to a bug

3 - Original developer can't fix it because it would break compatibility

4 GOTO 1

withinboredom 5 days ago | parent | next [-]

Immediately reminded of this: https://externals.io/message/126011 that is an ongoing conversation in php-internals about removing a quirky/buggy behavior from PHP that, at the very end (at least of this comment's time) someone jumps in and says "yep, its useful, please keep it"

Cthulhu_ 5 days ago | parent | prev [-]

And this isn't even quirky/buggy, it's just the string representation of an error. That said, Go took a while to improve its core error mechanisms and add utilities for matching errors by type instead of its string representation.

simiones 5 days ago | parent [-]

In this case, it really is - because until Go 1.19, that function simply returned `errors.New("http: request body too large")`. So until Go 1.19, there really was no other way to check if this error occurred than `err.String() == "http: request body too large"`. Even if we had had errors.Is/As earlier, it wouldn't have helped in this case.