On 2013/01/10 14:16, Tom Hendrikx wrote:
On 10-01-13 22:43, Kevin A. McGrail wrote:
On 1/10/2013 3:16 PM, Tom Hendrikx wrote:
Since I wrap spamc with a different programming language, I have all
the tools available to handle any error condition: detecting EX_TOOBIG
is however not possible.
I don't understand this as I use MD to call spamc. Why can't you just
check the file size prior to calling sa?
Because I don't want to maintain the maxsize in two places? Because I
still want to catch the error when someone lowers only the maxsize
settings because he did not RTFM?
I want to handle the error as spamc throws it at me, implementing a
second safety net is a waste. Given enough development time and cpu
cycles, I could safeguard against all possible errors that spamc is able
to return before I actually execute it, but it would be easier to just
build a new version of spamc in stead.
Otherwise, like I said, now's the time to open a bug and work on a patch
if you are interested in this.
Yes, that is why I was discussing the different options available.
Adding another 17 switches for different scenarios is ugly, the existing
6(!) already look disappointingly overcomplicated to me. So I'd be happy
to contribute a patch that contains an elegant solution, but not another
kludge that fixes only my stupid little issue but makes matters worse in
the long run. As said, creating a kludge in the surrounding code is just
as ugly, but much faster.
--
Tom
I'd suggest an option similar to the header option.
pass_errors 5,18,21,2,6
ignore_errors 23,3,19
Those example lines would guarantee errors 5 ,18 ,21 ,2, and 6 would pass
through to the consumer and suppress error notification for 23, 3, and 19.
If the lines are not in any config file then today's current behavior
would be exhibited.
It is simply expandable into the future if there is some interesting
reason for having to pass or ignore errors in a different manner than
the default manner.
{^_^}
