> Poor programmers do things like allowing an incoming request to spin up unlimited concurrent threads. Poor programmers erroneously throw exceptions on any operational deviation - even it if can be handled without error.
All of these examples make sense in the context of your business, but in some environments these might be best practice ;)
There's different levels of concern for a public API and an internal interface. If you control all publishers and subscribers, then you don't need to worry quite as much about sanity checking inputs or making every possible workable input produce a valid result.
There are plenty of environments where deviating from spec (even when fixing an apparently trivial bug) would not be ok without assessing the situation for potential unintended behaviors.
High-risk systems where a software bug could result in loss of life - aviation, submarine tech, defense, medical etc. Edit: This is for throwing exceptions on undefined behavior.
For unlimited threads I imagine scenarios exist particularly when scalable computing is so popular. Large high traffic web stores such as Amazon/Ebay, financial institutions, etc. Either way, the problem shouldn't be solved by an individual developer on a project making things up as they go - its a problem that probably needs to be defined at a framework layer, and discussed within the team of developers and requirements definers.
All of these examples make sense in the context of your business, but in some environments these might be best practice ;)