🚀 go-pugleaf

hagins@gamecock.rtp.dg.com (Jody Hagins) writes:

>|> 
>|> I should have been more verbose.  I was hoping people would be able to
>|> read between the lines.  My overall point is that trapping c/a/b is not
>|> a technical issue at all; it is a training issue.  You need to train
>|> your users that there are a few things they shouldn't do when using your
>|> software; the following lists some, but by no means all, of these things:
>|> 
>|> 	1) c/a/b
>|> 	2) reset
>|> 	3) turning the machine off
>|> 	4) unplugging the machine
>|> 	5) pouring Coke on the keyboard
>|> 	6) dropping the machine
>|> 	7) etc...
>|> 
>|> What trapping c/a/b really does is make it harder for the support
>|> programmer to deal with the machine, while not making it any harder for
>|> the user (intentionally or not) to do something "bad".
>|> 
>|> (This probably doesn't belong in this [technical] conference at all, but that
>|> is my $0.86 worth)
>|> 



>This brings up the debate of what is expected of the user.  In general,
>I have come to assume that all users are brain dead, and completely
>incompenent.  This assumption (the only safe assumption to ever make when
>writing software) keeps me at the keyboard an extra 10-20 percent doing
>extra testing, and error trapping.  However, it does keep the users happy,
>which, in turn keeps them coming back for more.

>By the way, I do NOT trap c/a/d (or cntrl-alt-panic as i have come to know it).
>The way I figure it, I cant trap the power switch, which could do the same,
>if not worse, damage, so I don't trap the sequence either.  The only thing it
>protects you from is a malicious user, which in that case, you pay to have
>your system secured, which would include keyboard locking, etc.


I agree completely with your last paragraph.  Exactly the point.

(BTW, it is c/a/d, not c/a/b.  For some reason, I was thinking
control/alt/break...)