If you stick to the PHP documentation: (refer to the link in my first
email):

\LogicException: Exception thrown if a logic expression is invalid
\BadMethodCallException: Exception thrown if a callback refers to an
undefined method or if some arguments are missing
\InvalidArgumentException: Exception thrown if an argument does not
match with the expected value

\RuntimeException: Exception thrown if an error which can only be
found on runtime occurs

And I think that the 3 listed errors can only be detected at runtime.

The example is picky but I think we should really answer the question
if some guidelines should be defined for Exceptions.

On Dec 23, 11:31 am, Tim Nagel <[email protected]> wrote:
> I dont see how there is an inconsistency?
>
> Calling getException() on a non existant extension is a logic exception
> Calling set on a frozen container is a bad method call, and
> calling getParameter with an invalid parameter is an invalid argument 
> exception.
>
> t
>
> On Thu, Dec 23, 2010 at 20:36, Victor Berchet <[email protected]> 
> wrote:
> > Does Sf2 define guidelines for throwing exceptions ?
>
> > For example the container builder would throw:
> > - a \LogicException when getExtension() is called for a non-registered
> > extension,
> > - a \BadMethodCallException when set() is called on a fronzen
> > container,
> > - a \InvalidArgumentException when getParameter() is called for a non-
> > existing parameter.
>
> > Obviously there is a lack of consistency here and even if the types
> > seem quite appropriate at first glance, they do not match the
> > definition given in the php documentation (http://fr.php.net/manual/en/
> > spl.exceptions.php). I think that strictly speaking all of the above
> > errors should throw a \RuntimeException.
>
> > There are multiple options:
> > 1. We don't care at all what type of exception are thrown,
> > 2. Let the developers pick the type they think is the most
> > appropriate,
> > 3. Define some guidelines on when to throw what type of Exception
> > (SPL, component level, ...)
>
> > Any thoughts ?
>
> > --
> > If you want to report a vulnerability issue on symfony, please send it to 
> > security at symfony-project.com
>
> > You received this message because you are subscribed to the Google
> > Groups "symfony developers" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]
> > For more options, visit this group at
> >http://groups.google.com/group/symfony-devs?hl=en

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to