Are we still having this discussion? :-)
At 07:23 PM 2/21/01 -0500, [EMAIL PROTECTED] wrote:
>Its true alot languages would consider many of Perl's warnings to be
>errors, that's not really analgous to what we're talking about here.
>
>Run-time errors aren't quite in the same spirit as run-time warnings.
>A run-time error is something the language defines as being explicitly
>bad or a mistake (even if it can be caught as an exception). Run-time
>warnings are just the language saying, "excuse me, there might be a
>problem here". An error is, "NO, YOU'RE WRONG!!"
>
>Errors and exceptions must be dealt with, else your program won't run.
>Warnings... they can be ignored.
I do not think there is hard dividing line between warnings and
errors. "Unable to establish network connection - saving file to local
disk" means the program is still running afterwards. The more
fault-tolerant your program is, the more your errors look like
warnings. Is that message an error or a warning?
> Warnings are often stylistic in
>nature, errors are not. An error is often a very concrete indication
>that something is wrong, a warning is not (if it was, it should be
>promoted to an error).
>
>With that in mind, do we have any analogies?
>
>I can think of some GUI analogies. Macster (the Macintosh Napster
>client)* requires that you confirm every download you cancel.
>Windows, by default, requires that you confirm everything you drop
>into the trash (or whatever they call it this week). Most software
>installers require that you click [Accept] after reading the
>agreement. Some even require that you scroll down to the bottom
>before letting you accept.
>
>The result? People either shut them off or mindlessly click [Ok].
>Nobody** sits there and things "gee, do I really want to throw this
>out?" Nobody reads software licenses.
Or government warnings on cigarettes.
>Its not that there's anything wrong with these ideas, but its the
>continual bombardment which dulls the senses against them. If the
>user has internalized the need for them (say, they once deleted a file
>which cost them their job) then it might be helpful.
>
>Similarly, a wet-behind-the-ears programmer will not give Perl's
>warnings much credence if their program runs fine despite of them.
>They will be ignored until such time as they internallized, through
>error or teaching.
I suppose I'm in an exceptional class then, 'cos whatever language I'm
using, any warning at any time causes me to stop what I'm doing, and fix
the cause. Even if that means selectively ignoring the warning through a
pragma. I've been doing this since I used Saber C (actually before that,
too): fix the cause, or put an ignore directive in. Never mind how picky
it seems.
I am somewhat frightened by the prospect of anyone programming with a
mindset that warnings are okay, and even more by the philosophy that we
should cater more to them than more careful people.
What if the warnings were:
1/100 chance of destroying your files at this point... you win!
1/100 chance of producing incorrect output at this point... you win!
1/100 chance of losing user data at this point... you win!
...
What if the warnings boiled down to that anyway?
--
Peter Scott
Pacific Systems Design Technologies
