Your argument is just reinforcing the reason for errors to be concise and to the point rather than displaying a stack track when it’s not the developers who are administering the application.
Trust me, searching through a stack trace on a centralised logging system isn’t fun.
> Finally, even in personal desktop software, the environment is jointly owned by the user and the developer - the developer is normally responsible for setting up the initial environment through some kind of installer (msi, deb, make configure etc.), and many environment issues are bugs in the installer, not user errors.
Desktop Linux, yeah. It’s seldom that simple in servers though. SELinux, custom config, custom iptables rules, network wide UIDs (eg shared storage volumes), there’s so much that can go wrong the moment you do enterprise.
> Note that even the reverse is not clear; an index out of bounds error could be a user problem - if they are trying to access the 7th element of a 5 element list. The fact that you'd normally do
If you’re writing software that doesn’t do input validation and bounds check then you’re a failure of a developer. Sorry but this is the bare minimum I’d expect a developer to do.
> Trust me, searching through a stack trace on a centralised logging system isn’t fun.
A stack trace is still better than a one line error with no context. It's a kind of 80% solution - it's not ideal (a perfect error includes only the relevant context), but getting it's much better for 0 effort than error codes/values give you for free.
> If you’re writing software that doesn’t do input validation and bounds check then you’re a failure of a developer. Sorry but this is the bare minimum I’d expect a developer to do.
So what is the profound difference between doing input validation in your own code vs letting the array accessor do it?
> A stack trace is still better than a one line error with no context. It's a kind of 80% solution - it's not ideal (a perfect error includes only the relevant context), but getting it's much better for 0 effort than error codes/values give you for free.
Yeah, a stack trace is better then an “undefined error” type message. But the point of forcing error messages over exceptions is you’re enabling you’re developers to write meaningful error messages. So your point is moot.
> So what is the profound difference between doing input validation in your own code vs letting the array accessor do it?
- Meaningful error messages (eg has the code failed because of a bug or because of invalid user input?),
- security hardening,
- reducing potential undefined behaviours,
- thorough unit testing,
- self documenting code (the code clearly defines what the happy path is and when it’s possible for a user to break out from that)
Trust me, searching through a stack trace on a centralised logging system isn’t fun.
> Finally, even in personal desktop software, the environment is jointly owned by the user and the developer - the developer is normally responsible for setting up the initial environment through some kind of installer (msi, deb, make configure etc.), and many environment issues are bugs in the installer, not user errors.
Desktop Linux, yeah. It’s seldom that simple in servers though. SELinux, custom config, custom iptables rules, network wide UIDs (eg shared storage volumes), there’s so much that can go wrong the moment you do enterprise.
> Note that even the reverse is not clear; an index out of bounds error could be a user problem - if they are trying to access the 7th element of a 5 element list. The fact that you'd normally do
If you’re writing software that doesn’t do input validation and bounds check then you’re a failure of a developer. Sorry but this is the bare minimum I’d expect a developer to do.