On 7/01/2013 10:42 p.m., Kinkie wrote:
>> IMO, Squid should abort when it cannot be sure its interpretation of a
>> configured value is correct. I agree that, in some cases, the caller is
>> more knowledgeable about parsing context and may decide to proceed
>> anyway or generate a better error message. However, I think the default
>> should be to abort.
>>
>> In C++, this kind of problem is handled nicely by exceptions: If the
>> caller wants to treat the error condition specially, it can catch the
>> exception. Otherwise, the exception is propagated to the default handler
>> (which aborts, showing the exception-derived error message).
> +1. I like this whole idea.
>
>> I realize that others believe that starting Squid is more important than
>> starting Squid with correct/intended configuration and so the default
>> should be to report and ignore errors. The consensus may [still] favor
>> that point of view. (Perhaps the default choice should be configurable.)
> Hm.. I'm inclined towards being rigid here (not start), but some
> configuration values which only affect performance (and not security)
> may have a more relaxed attitude. In all cases, caller knows best.
Exactly. Exceptions or explicit error return codes, I'm not too
particular about the details. But I am sure these abort() need to be
moved if nothing else. The current position is too ambiguous in the
reporting.
Amos
Received on Thu Jan 10 2013 - 08:43:13 MST
This archive was generated by hypermail 2.2.0 : Thu Jan 10 2013 - 12:00:05 MST