4 ms·
Obviously it isn’t totally impossible, but it becomes challenging to know if it’s required or not. It’s hardest when it isn’t just throwing an error but instead
by mmillin 3mo ago
Obviously it isn’t totally impossible, but it becomes challenging to know if it’s required or not. It’s hardest when it isn’t just throwing an error but instead defaulting to something only half-sensible. For example replacing a negative number with 0 or overflowing rather than panicking.
When it comes to assumptions about the input, ideally model them in the type system. If you can’t, explicit checks and throws are OK in my book. But don’t check-and-hide any errors. You’ll be hard pressed to debug the issues they’ll cause down the road, since it will usually be far from the implementation that you see the impact.
- fwip 3mo agoI hate the "pick defaults out of a hat" approach that LLMs seem to take. I suspect this behavior may be a result of reenforcement learning on coding challenges - making the code worse by throwing in these assumptions (which in turn become part of your documented API) may get you an extra half percentage point on the code challenges.