I work with old and new code bases used by many clients in complicated setups, but adding a warning to stderr while stdout was left untouched, and proper exit codes maintained, was hardly, if ever, a problem so far.
Of course, there's always some unpleasant exception, but it's rare.
And of course, I also understand that the author might have found themselves not only in one of those rare-ish instances, but also one where reasoning with the other side was fruitless.
You drop a little stderr print in your library saying “foo is deprecated, please use bar”, but then that library is included in another library which included in a CLI called by a script somewhere and, now the output goes to someone’s terminal when they’re running some management CLI. They never wrote the call to foo, they don’t even know what a foo is, they are 3 layers removed from who the target audience is.
Runtime is never the time to alert to things like deprecations or “this shouldn’t be used this way” notices. For deprecations, use your language’s built-in way of making functions deprecated. If your language doesn’t have that, use a real programming language. For other types of warnings, if you’re not 100% sure your message will only be seen by the developer who can fix it, just don’t write it.
Ah yes, Schroedinger's workflow. So important any disruption is a disaster, and simultaneously so unimportant they couldn't possibly spend a single dime on the tools critical to the workflow.
- sometimes you can get the status code, sometimes you can't.
- sometimes you can separate out stdout from stderr, sometimes you can't
- sometimes the program generating the error message identifies itself, sometimes it doesn't
- sometimes you don't know if you have a "good error" (ok to ignore) or a "bad error" (cannot ignore)
I am a fan of the HARD FAIL.
I think internal unit tests or things like that should hard fail, then get a human to either fix it, or put in a hard exception.
if it is user-facing... sigh
If it's commercial software, you're paid to make it work, no matter how stupid that may be, and forced stupidity isn't your problem.
If it's FOSS, you can tell the user to deal with it and close the ticket.
