2017-04-16 3 views
1

je extraits de code:RuntimeException même quand ont essayer prises

try {     
    AlgorithmParameterSpec spec = null; 
     synchronized (lock) { 
     // ... 
     KeyPairGenerator generator = KeyPairGenerator.getInstance(RSA_ALGORITHM, PROVIDER_ANDROID_KEY_STORE); 
     generator.initialize(spec); 
     generator.generateKeyPair();     
     } 
     } catch (Throwable e) { 
      Logger.e("Exception " + e.getMessage() + " occurred",e); 
     } 

Sur les appareils avec la version SDK < 23 Je reçois java.security.ProviderException en ligne generator.generateKeyPair(); et application tombe en panne!

Ma question est: pourquoi l'application se bloque si j'ai essayé/catch?

De cette réponse: Why we don't have to add try-catch to a RuntimeException?

C'est parce qu'il est une exception non contrôlée. Il n'a pas besoin d'être explicitement déclaré ou attrapé. Voir aussi le tutoriel Sun sur le sujet .

mais je ne pense pas que son mon cas

Ma trace de la pile:

8:28:39.700 9359-10032/com.hoo.app.dev E/art: JNI DETECTED ERROR IN APPLICATION: JNI FindClass called with pending exception 'java.security.ProviderException' thrown in unknown throw location 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: in call to FindClass 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: from byte[] com.google.android.gms.org.conscrypt.NativeCrypto.EVP_DigestSignFinal(com.google.android.gms.org.conscrypt.NativeRef$EVP_MD_CTX) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: "pool-7-thread-1" prio=5 tid=66 Runnable 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: | group="main" sCount=0 dsCount=0 obj=0x12da8400 self=0x7f87147800 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: | sysTid=10032 nice=0 cgrp=default sched=0/0 handle=0x7f9206a000 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: | state=R schedstat=(60197617 2542383 67) utm=6 stm=0 core=1 HZ=100 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: | stack=0x7f646fe000-0x7f64700000 stackSize=1036KB 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: | held mutexes= "mutator lock"(shared held) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.google.android.gms.org.conscrypt.NativeCrypto.EVP_DigestSignFinal(Native method) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.google.android.gms.org.conscrypt.OpenSSLSignature.engineSign(:com.google.android.gms:224) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.security.Signature$SignatureImpl.engineSign(Signature.java:672) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.security.Signature.sign(Signature.java:381) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.android.org.bouncycastle.x509.X509Util.calculateSignature(X509Util.java:248) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.android.org.bouncycastle.x509.X509V3CertificateGenerator.generate(X509V3CertificateGenerator.java:434) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.android.org.bouncycastle.x509.X509V3CertificateGenerator.generate(X509V3CertificateGenerator.java:412) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at android.security.AndroidKeyPairGenerator.generateKeyPair(AndroidKeyPairGenerator.java:133) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.security.KeyPairGenerator$KeyPairGeneratorImpl.generateKeyPair(KeyPairGenerator.java:276) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.myprog.MyKeystoreWrapper.createKey(SourceFile:147) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: - locked <0x2b1e5aea> (a java.lang.Object) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.myprog.MyKeystoreWrapper.createFirstInstallData(SourceFile:70) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.myprog.MyProgLib.getReInstallData(SourceFile:675) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.myprog.MyProgLib.sendTrackingWithEvent(SourceFile:1110) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.myprog.MyProgLib.access$600(SourceFile:72) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at com.myprog.MyProgLib$d.run(SourceFile:2253) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.util.concurrent.FutureTask.run(FutureTask.java:237) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:152) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:265) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) 
01-13 18:28:39.700 9359-10032/com.hoo.app.dev E/art: at java.lang.Thread.run(Thread.java:818) 

ligne: com.myprog.MyKeystoreWrapper.createKey(SourceFile:147) points ma méthode

+0

publiez votre pile complète – njzk2

+0

Dans 99,9999% des cas, les applications Java ne se bloquent pas. Les applications Java ont tendance à lancer des exceptions. Il n'est pas clair dans votre message comment vous savez que vous obtenez cette exception sur cette ligne, mais vous semblez réussir à attraper l'exception, c'est probablement comme ça que vous le savez. Donc, peu importe ce que vous considérez comme un «crash», c'est quelque chose que vous ne nous avez pas montré, et nous ne savons rien. S'il vous plaît soyez plus précis sur ce qui se passe précisément, et précisément comment vous savez (ou vous pensez savoir) ce qui se passe. –

+0

Probablement quelque chose d'autre se bloque par la suite. – EpicPandaForce

Répondre

2

java.security.ProviderException:

Exception d'exécution pour les exceptions de fournisseur (par exemple, m isconfiguration erreurs ou erreurs internes irrécupérables), qui peuvent être sous-classées par Fournisseurs pour lancer des erreurs d'exécution spécialisées spécifiques au fournisseur.

Il se réfère entre autres choses: erreurs internes irrécupérables.
Dans ce cas, cela signifie que l'interception de l'exception est inutile car l'erreur arrêtera l'application.
Vous êtes probablement dans ce cas.


Sur les appareils avec la version SDK < 23 Je reçois java.security.ProviderException en ligne generator.generateKeyPair(); et les plantages d'application!

Si ce bug n'est pas résoluble pour les appareils avec la version SDK < 23, vous devez tester la version du SDK dans le code et appliquez une alternative pour cette tâche de fixation.

+0

a ajouté une trace de pile – snaggs

1

Comme mentionné dans votre recherche, les exceptions non contrôlées n'ont pas besoin d'être explicitement déclarées. Les exceptions non vérifiées se produisent lorsque le compilateur ne peut pas vérifier qu'aucune exception d'exécution ne se produira.

Comme expliqué dans ce post: How to catch an Exception from a thread

Je pense que l'exception se produit dans un thread séparé et donc vous ne pouvez pas l'attraper avec votre clause catch autour.Le poste avec la plupart des votes (Dan Cruz) utilise la méthode suivante qui est exposée par la classe du fil:

setUncaughtExceptionHandler(ThreadExceptionHandler)

En utilisant la solution suggérée par l'utilisateur Dan Cruz, je pense que vous êtes en mesure de capturez cette exception d'exécution ..