Re: ArchiveIterator fault handling

[Justin Mason <jm...@jmason.org>]

-----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-----