| ▲ | ivan_gammel 4 hours ago |
| TBH, I do not see how Java as a language steers anyone to use one those shotguns. E.g. the knowledge about algorithmic complexity is foundational, the StringBuilder is junior-level basic knowledge. |
|
| ▲ | nightpool an hour ago | parent | next [-] |
| How would you handle validating numeric input in a hot path then? All of the solutions proposed in #5 are incomplete or broken, and it stems from the fact that Java's language design over-uses exceptions for error handling in places where an optional value would be much safer and faster. |
| |
| ▲ | ivan_gammel an hour ago | parent [-] | | Normally in 100% cases, with parseInt/parseDouble etc. Getting NumberFormatException so frequently on a hot path that it impacts performance means, that you aren’t solving the parsing number problem, you are solving a guessing type problem, which is out of scope for standard library and requires custom parser. | | |
| ▲ | nightpool an hour ago | parent [-] | | Okay, but this contradicts your original statement that "Java doesn't steer anyone to use these [footguns]". Every language has a way to parse integers, and most developers do not need a custom parser. Only in Java does that suddenly become a performance footgun. | | |
| ▲ | ivan_gammel an hour ago | parent [-] | | It does not. If you need to parse a number, you use standard library and you will be fine. The described case with huge impact on hot path is the demonstration why using brains is important. The developer that will get into this mess is the one who will find the way to suffocate his code with performance bottlenecks in thousand other ways. It’s not a language or library problem. | | |
| ▲ | dionian 17 minutes ago | parent [-] | | Yes, parseInt et al work very fast for good inputs. What percentage of your inputs are invalid numbers and why ? |
|
|
|
|
|
| ▲ | 3 hours ago | parent | prev [-] |
| [deleted] |
