Ne peut pas attraper symfony FatalErrorException

J'ai un code comme ceci:

try {
    $var = $object->getCollection()->first()->getItem()->getName();
} catch(\Exception $e) {
    $var = null;
}

Bien sûr, j'ai communicative variables et les noms de méthode. C'est juste la démonstration.

Donc si ma collection est vide la Collection: d'abord en() retournera false. Puis le getItem appel jeter un Symfony\Component\Debug\Exception\FatalErrorException qui ne sera pas attrapé par le code ci-dessus.

Ma question est que comment puis-je attraper cette exception? J'ai de longues chaînes comme cela avec de nombreuses méthodes qui peuvent retourner la valeur null. Donc, je préfère cette façon plutôt que de vérifier chaque valeur null.

avez-vous essayé de l'attraper (\FatalErrorException)
j'ai essayé de l'attraper(Symfony\Component\Debug\Exception\FatalErrorException) et la capture(\ErrorException).

OriginalL'auteur Jumi | 2015-02-09

  1. 30

    Utilisation Throwable classe au lieu Exception classe:

    try {
    $var = $object->getCollection()->first()->getItem()->getName();
} catch(\Throwable $e) {
    $var = null;
    $msg = $e->getMessage();
}

    Depuis PHP 7.0 exceptions levées de fatal et de recouvrement des erreurs sont des instances d'une nouvelle classe d'exception: Error. Cette nouvelle Error classe implémente Throwable interface, qui spécifie les méthodes presque identiques à ceux de Exception. Parce que Throwable est plus élevé dans la hiérarchie, vous pouvez prendre à la fois, \Erreur et \Exception.

    interface Throwable
|- Exception implements Throwable
    |- ...
|- Error implements Throwable
    |- TypeError extends Error
    |- ParseError extends Error
    |- ArithmeticError extends Error
        |- DivisionByZeroError extends ArithmeticError
    |- AssertionError extends Error
    Je peux confirmer cela résout le problème, mais je ne comprends pas pourquoi. Symfony est FatalErrorException s'étend \ErrorException, qui s'étend \Exception. Le fait que PHP a maintenant Error comme une classe de base ne semble pas pertinent car il n'est pas dans la hiérarchie d'héritage pour FatalErrorException. Quelqu'un peut-il m'expliquer?

    OriginalL'auteur

  2. 13

    Comme vous pouvez le voir ici, FatalErrorException s'étend ErrorException (PHP) qui s'étend php Exception classe.

    Maintenant que vous avez tous ces éléments, vous êtes prêt pour l'étape suivante: le nom de l'exception dit, c'est un FatalError (un concept lié à PHP, et pas avec Symfony2; dans ce cas, on construit une classe wrapper pour cette erreur, peut-être pour l'interface).

    Une erreur fatale de PHP n'est pas un catchable on est donc assez inutile de conserver le code qui pourrait causer la FatalError, à l'intérieur d'un try ... catch bloc

    Vous devez vérifier, comme un bien commun et de la bonne règle, chaque fois que possible pour les valeurs renvoyées avant d'essayer d'y accéder.

    Connaissez-vous un outil qui a des caractéristiques similaires à la valeur par défaut de rameau filtre?
    que voulez-vous dire?
    Je veux dire quelque chose comme ceci: twig.sensiolabs.org/doc/filters/default.html
    Je sais à propos de "défaut de rameau filtre". Ce que je ne peux pas comprendre ici est que voulez vous dire par "un outil"? Quel outil? Un PHP?
    Oui. Une bibliothèque, d'une fonction, quelque chose qui me tient à l'écart de l'écriture des conditions pour tous les getters. Comme symfony propriété accesseur aurait retourne un objet contenant qui d'échec de l'appel de la chaîne.

    OriginalL'auteur

  3. 1

    Ok. J'ai trouvé une solution de contournement. J'utilise la propriété de l'accesseur composant qui met en simple exceptions près, les erreurs non fatales.

    $pa = \Symfony\Component\PropertyAccess\PropertyAccess::createPropertyAccessor();
try {
    $var = $pa->getValue($object, 'collection[0].item.name');
} catch(\Exception $e) {
    $var = null;
}
    L'utilisation d'exceptions pour la logique/flux de contrôle est une mauvaise idée. J'espère que vous ne livrons pas les blocs de code comme celui ci-dessus dans n'importe quel environnement de production.
    Fait ses un schéma très commun dans certains langages comme Python, où ils expriment comme "Il est plus Facile de demander Pardon que Demander la Permission." (voir en.wikipedia.org/wiki/Python_syntax_and_semantics#Exceptions)

    OriginalL'auteur

  4. 0

    Fonctionne pour moi (PHP 7.0, Symfony 3.0.9):

    use Symfony\Component\Debug\Exception\FatalThrowableError;
...
try {
    throw new FatalErrorException("something happened!", 0, 1, __FILE__, __LINE__);
} catch (FatalErrorException $e) {
    echo "Caught exception of class: " . get_class($e) . PHP_EOL;
}

    De sortie:

    Caught exception of class: Symfony\Component\Debug\Exception\FatalErrorException

    OriginalL'auteur

  5. -2

    Pouvez-vous essayer ceci:

    $foo = $object->getCollection()->first();
if($foo){
  $var = $foo->getItem()->getName();
} else {
    //fallback
}

    OriginalL'auteur