Est-il un moyen de lancer une exception sans ajouter le jette déclaration?

J'ai la situation suivante.

J'ai une Classe Java qui hérite d'une autre classe de base et remplace une méthode.
La méthode de base ne permet pas de lancer des exceptions et n'a donc pas throws ... déclaration.

Maintenant ma propre méthode devrait être en mesure de jeter l'exception mais j'ai soit le choix de

Avaler l'exception
Ajouter un lève déclaration

À la fois un pas satisfaisant parce que le premier serait ignorer en silence l'exception (ok, j'ai pu effectuer des coupes) et la deuxième serait de générer des erreurs de compilation à cause de la méthode des en-têtes.

public class ChildClass extends BaseClass {

        @Override 
        public void SomeMethod() {
            throw new Exception("Something went wrong");
        }
}

InformationsquelleAutor Jürgen Steinblock | 2010-12-23

exception-handling java

89

Vous pouvez jeter décoché exceptions sans avoir à déclarer que si vous le voulez vraiment. Décochée exceptions étendre RuntimeException. Throwables qui s'étendent Error sont également décoché, mais devrait être utilisé seulement pour vraiment sérieux problèmes (comme invalide bytecode).

Comme un cas spécifique, Java 8 ajouté UncheckedIOException pour l'emballage et le renvoi des IOException.
- Fonctionne très bien, j'ai renvoyer une RuntimeException parce que l'exception vient d'une autre méthode, mais elle fonctionne très bien, merci.
InformationsquelleAutor OrangeDog

Voici une astuce:

class Utils
{
    @SuppressWarnings("unchecked")
    private static <T extends Throwable> void throwException(Throwable exception, Object dummy) throws T
    {
        throw (T) exception;
    }

    public static void throwException(Throwable exception)
    {
        Utils.<RuntimeException>throwException(exception, null);
    }
}

public class Test
{
    public static void main(String[] args)
    {
        Utils.throwException(new Exception("This is an exception!"));
    }
}

Je me demande comment cela fonctionne? Je vais faire quelques recherches, mais avez-vous des ressources, qui peut m'aider? 🙂
T déduit que RuntimeException. La réponse ici stackoverflow.com/questions/41380656/... ici stackoverflow.com/questions/31316581/...
Génial l'astuce! Cette astuce peut également s'appliquer sur l'expression lambda/bloc, afin de permettre l'attribution de l'extrait exception de la méthode de la SAM interface sans throws déclarations.

InformationsquelleAutor Eng.Fouad

26

Une troisième option est d'opter pour la exception de la vérification (tout comme la Norme API en elle-même a faire parfois) et l'enveloppe de l'objet d'une exception dans un RuntimeException:
```
throw new RuntimeException(originalException);
```
Vous pouvez utiliser une sous-classe spécifique de RuntimeException.

InformationsquelleAutor Michael Borgwardt
8

Je veux juste faire ajouter une alternative réponse, purement comme un FYI:

Oui, il y a un moyen de jeter un checked exception sans ajouter le throws déclaration, à l'aide de la sun.misc.Unsafe classe. Ceci est décrit dans le blog suivant:

Jetez un checked exception à partir d'une méthode sans la déclarer

Exemple de code:
```
public void someMethod() {
  //throw a checked exception without adding a "throws"
  getUnsafe().throwException(new IOException());
}

private Unsafe getUnsafe() {
  try {
    Field field = Unsafe.class.getDeclaredField("theUnsafe");
    field.setAccessible(true);
    return (Unsafe) field.get(null);
  } catch (Exception e) {
    throw new RuntimeException(e);
  }
}
```
Cependant, ce n'est pas recommandé. Il est préférable d'envelopper dans un décoché exception comme indiqué dans les uns des autres réponses.
- Il y a une raison pour qu'ils appellent la classe Unsafe.
InformationsquelleAutor dogbane
4

Pourquoi ne pas jeter un décoché exception? Cela n'a pas à être déclarée.

Deux alternatives sont
- envelopper avec un contrôle exception avec un décoché un.
- ne pas permettre au compilateur de savoir que vous êtes jeter un checked exception par exemple du Fil.currentThread().stop(e);
- Dans la version 6 de Java, vous pouvez renvoyer l'exception, si c'est final et le compilateur de savoir qui a vérifié les exceptions que vous pourriez avoir pris.
- Dans Java 7, vous pouvez renvoyer une exception si elle est effectivement final, c'est à dire que vous ne l'avez pas changé dans le code.
Le plus tard est plus utile lorsque vous lancer une exception de contrôle dans votre code et l'attraper dans votre code d'appel, mais les couches inbetween ne sais rien à propos de l'exception.
- -1 pour suggérer obsolète fonctions
- La deuxième méthode est intéressant, aussi. Mais pour le moment, l'emballage, l'exception est exactement ce dont j'ai besoin.
- download.oracle.com/javase/6/docs/technotes/guides/concurrency/...
- puisque vous avez lu cela, pouvez-vous me dire quelle est la différence entre l'utilisation de stop() sur le thread en cours et en jetant un enveloppé exception. 😉
- "la méthode suivante est sur le plan comportemental identique à Java jet de fonctionnement, mais contourne le compilateur tente de garantir que la méthode d'appel a déclaré l'ensemble de l'objet d'exceptions qu'il peut jeter" comment se termine l'exception mieux?
- "L'arrêt d'un thread causes pour débloquer tous les écrans qu'il a verrouillé. Si l'un des objets préalablement protégé par ces moniteurs ont été dans un état incohérent, d'autres threads peuvent maintenant voir ces objets dans un état incohérent. [...] Contrairement à d'autres décoché exceptions [...] l'utilisateur n'a pas d'avertissement que son programme est peut-être endommagé."
- Qui s'applique si vous vous arrêtez un autre thread dans un endroit aléatoire, mais si vous "d'arrêter" le même thread, elle n'est pas dans un endroit aléatoire et est "sur le plan comportemental identique à Java de lancer l'opération" c'est à dire son pas plus dangereux que de jeter un décoché exception ou une erreur.
- Hormis le fait que c'est un horrible et inutile hack, toute tentative pour attraper l'exception entraînera les avertissements du compilateur. Plus personne à l'aide de votre code m'attendais pas à jeter checked exceptions sans être déclaré, de faire des erreurs d'omission hautement probable. Dans le pire des cas, le compilateur peut optimiser les choses, en supposant que (relativement) que les exceptions ne seront pas jetés sans déclaration. Ne pensez pas que vous savez mieux que la langue concepteurs quand ils explicitement de vous dire de ne pas faire quelque chose.
- Bien que tout cela est vrai, je ne peux que conclure que vous ne pense pas que l'habillage de l'exception est mieux (comme tous vos points s'appliquent à cette approche) et ont évité de répondre à cette question. À mon humble avis, le pire comme il obscurcit l'exception d'origine. BTW: Le compilateur n'a que très peu d'optimisations le JIT est-ce que 99% d'entre eux.
- Quid du cas où on a besoin de prendre note de toute exception qui se produit, quel que soit son type, puis renvoyer de la même exception? Si une des méthodes appelées à partir d'un try bloc sont déclarées comme jeter quelques différents checked exceptions, la capture et le renvoi des Exception serait plus propre que de l'attraper et de renvoi de chaque individu d'exception à l'intérieur des méthodes de pourrait lancer, mais à moins que l'on puisse "secrètement" rethrow je ne sais pas comment faire le compilateur tolérer un fourre-et-rethrow de Exception.
- Je ne vois pas de situation où vous seriez besoin pour le faire. Si vous pensez que vous le faites, alors il y a probablement quelque chose de mieux, vous pouvez être en train de faire.
- Parfois, il est nécessaire pour que le code dans un finally bloc à savoir si le try bloc réussi (entre autres choses, il peut être approprié de supprimer une exception qui se produit dans le finally bloc si et seulement si le try bloc a également lancé une exception--un modèle utilisé par Java lui-même dans le try-with-resources). Le code de poignée qui devrait être agnostique pour le type de l'exception en cause; cela ressemble à de la version 6 de Java, il peut être.
InformationsquelleAutor Peter Lawrey
2

Oui, il y a un pourquoi, mais il n'est pas recommandé, vous pouvez utiliser :

Java dangereux paquet
```
getUnsafe().throwException(new IOException());
```
Cette méthode lève vérifié exception, mais votre code pas obligé de l'attraper ou de renvoyer il. Tout comme exception d'exécution.

InformationsquelleAutor Ahmad Al-Kurdi

Voici un exemple pour l'interception vérifié les exceptions et les emballer dans un décoché exception:

public void someMethod() {
   try {
      doEvil();
   }
   catch (IOException e)
   {
       throw new RuntimeException(e);
   }
}

InformationsquelleAutor Jason S

0

vous pouvez intercepter l'exception avec bloc try - catch dans votre méthode substituée.
ensuite, vous n'avez pas besoin de déclarer lancers - déclaration.
- bien sûr, mais ensuite je voudrais avaler l'exception, ce qui est exactement le contraire de ce que je veux arriver 😉
InformationsquelleAutor Erhan Bagdemir
-1

Vous pouvez utiliser n'importe quelle exception dérivé de RuntimeException ou RuntimeException lui-même

ou

utiliser un try-bloc de l'exception de jeter le code de poignée et il y

InformationsquelleAutor fmucar

Vous devez vous connecter pour publier un commentaire.