Message226289
| Author |
dhduvall |
| Recipients |
Oliver.Jeeves, dhduvall, dstufft, eric.araujo, tarek |
| Date |
2014年09月02日.22:47:26 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1409698046.94.0.26489698223.issue7918@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Absolutely true that developers should have tests that would detect such bugs. However, the sooner you detect a bug, the more time you save. And by the time it reaches someone like me, who is just packaging up the module for distribution with an OS, it's just going to waste my time, too, with less benefit (because I'm still not going to have much of an incentive to write tests).
Imagine if your C compiler only warned about code that wouldn't compile, and failed to produce the corresponding .o file without erroring out, and the linker failed to error out when that .o file was missing, and that you only noticed the problem when you ran your tests (or, if you're just shipping someone else's code, when your customer calls you to complain). Wouldn't you think that was stunningly broken?
Again, I get that there are use cases for having broken code pass through unscathed, but it seems very odd to me (as someone with a long unix background) that this would have been a conscious default. Now that it is the default, I understand the need for caution, but caution needn't (and shouldn't) prevent bugs from getting fixed. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2014年09月02日 22:47:27 | dhduvall | set | recipients:
+ dhduvall, tarek, eric.araujo, Oliver.Jeeves, dstufft |
| 2014年09月02日 22:47:26 | dhduvall | set | messageid: <1409698046.94.0.26489698223.issue7918@psf.upfronthosting.co.za> |
| 2014年09月02日 22:47:26 | dhduvall | link | issue7918 messages |
| 2014年09月02日 22:47:26 | dhduvall | create |
|