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
