-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Quinlan writes: > I'm cleaning up the fault-handling in mass-check a bit for some of my > own scripting. My main question: should ArchiveIterator return a fatal > error (that would propagate up) if a target is not accessible? All of > those reading/scanning functions just "return;" regardless of errors. in my opinion, if a target listed by the user (e.g. a directory or mbox name listed on the command line) does not exist, then a reasonable way to deal with that would be to die() and let the calling code deal with it. Why have the caller deal with it? In some cases, this would not be appropriate as a fatal error, as I've often run into it myself when removing an old mail folder and I don't want the entire mass-check/sa-learn/etc. to fail; however, if I'm removing markup using "spamassassin", I *would* want the script to fail with a clear exit code in that case. (It might be appropriate to carry on and return an exit code in the spamassassin/sa-learn cases.) However, if it's just that something *inside* one of those user-listed targets disappears, that's definitely non-fatal. This happens regularly if you scan live mail folder Maildirs, and delete a messge between mass-check start time and when it gets to scanning that file. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFCXDoRMJF5cimLx9ARAkenAKC3YK+hmCoBhlQQFxJa336ijXbQKwCgkZI2 r4xSPlgcPPLp1Gk3rO9CzrA= =iz6S -----END PGP SIGNATURE-----
