From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: <20030911160106.Y2507@cackle.proxima.alt.za>, Subject: Re: [9fans] ... in the Kingdom of Sources Date: Fri, 12 Sep 2003 09:18:22 +0000 Topicbox-Message-UUID: 32344bc4-eacc-11e9-9e20-41e7f4b1d025 rog@vitanuova.com wrote: > is truncating a 1MB file to 512K due to a mid-stream dud character > really a better solution than just flagging the dud character itself? > as you suggest, the answer is subjective, but surely the old maxim is > useful: > be liberal in what you accept and strict in what you generate. The trouble is, most programs are data transformers, and garbage in means garbage out *unless* the garbage is detected and an appropriate strategy used to deal with it. What is appropriate depends on the intended application. An impossible character encoding in input text data indicates that the preceding process did not do *its* job. Naturally you want to be able to handle such situations. But merely ignoring the fact that something is wrong and proceeding with the computation just propagates the error; it doesn't "fix" the situation. It probably doesn't matter much if you're just hacking, but if something important depends on having correct data, a better strategy is called for. I would hate to think that the codes sent to a respirator or pneumatic brake hadn't been correctly generated. I admit that lazy programming is more fun. So have fun, but don't think that an approach that has different goals is therefore inherently deficient.