Discussion :

[Auteur]

bonjour,


j'ai une application qui peut dans certains cas provoquer une erreur de type "java.lang.OutOfMemoryError: Java heap space". Je voudrais gérer convenablement cette erreur : dans mon cas il s'agirait de fermer simplement l'application.

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
try
{
    // mon code qui provoque l'erreur
 
}
catch (OutOfMemoryError ex)
{
	JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
	Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
	System.gc();
	System.exit(-1);
}
catch (Error ex)
{
	JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
	Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
	System.gc();
	System.exit(-1);
}
catch(Exception ex)
{
	JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
	Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
	System.gc();
	System.exit(-1);
}

Ce code fonctionne très bien mais toutefois, je voudrais savoir si ma manière dé gérer cette erreur est "propre", à savoir :
- j'appelle le carbage collector (pour détruire les objets et vider la mémoire ) ;
- je fais un exit(-1) : je ne devrais pas plutôt faire un dispose()


pour vos conseils.

[ttttnht]

Bonjour,

Normalement avec Java on n'a pas besoin de gc (c'est Java qui gere lui-meme ce genre de choses).

Pour dispose: Java gere ca normalement tu n'as pas besoin de le faire.

Quant au exit avec -1 si tu veux retourner un code de retour comme sous *nix.

[gronono]

Si tu as OutOfMemoryError, tu arrives encore à créer des objets ?

[adiGuba]

Salut,

Normalement avec Java on n'a pas besoin de gc (c'est Java qui gere lui-meme ce genre de choses).

+1
Dans 99% des cas le System.gc() est contre-productif et peut engendrer de mauvaise performance... en plus d'être inutile !

C'est le cas ici car le GC va faire tout son possible pour libérer la mémoire avant de remonter une OutOfMemoryError.
Et à la fin de l'application la JVM libère toute la mémoire d'un bloc (ce qui est bien plus performant).

Quant au exit avec -1 si tu veux retourner un code de retour comme sous *nix.

Le exit() suffit amplement pour fermer l'application et tous ses éléments graphiques. Il me semble toutefois qu'on utilise en général un code de retour positif, mais c'est un détail...

Maintenant il est peut-être préférable de fermer explicitement certaines ressources qui pourrait se retrouver bloquer pendant un certain temps (comme une connexion réseau par exemple), mais il n'y a pas de problème pour tout ce qui concerne l'interface utilisateur...


Mais au cas où tu tu peux utiliser les shutdown hook, qui seront exécuté juste avant la fin de ton application quelque soit la manière dont elle se termine :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	Runtime.getRuntime().addShutdownHook(new Thread() {
		@Override
		public void run() {
			//
			System.out.println("Bye bye...");
		}
	});

Si tu as OutOfMemoryError, tu arrives encore à créer des objets ?

Bonne remarque !

En fait cela dépend de l'état de ton application. Prenons par exemple une application limité à 64Mo.

Si tu utilises réellement 32Mo et que ton application tente d'allouer encore 40 Mo cela va provoquer une OutOfMemoryError, mais en sortie de cela ton application se retrouve à nouveau à 32Mo (les 40 n'ont pas pu être alloué) et tu peut donc allouer de nouveaux objets. Toutefois il n'est pas vraiment conseiller de continuer l'application comme si de rien n'était car il y a de forte chance que cela se reproduise...

Maintenant si petit à petit ton application approche des 64Mo d'utilisation réelles, alors tu peux en effet rencontrer des problèmes à nouveau jusque dans le code de traitement de ton exception (par exemple car il n'y a toujours pas assez de mémoire pour le JOptionPane). Cela peut être problématique car alors le exit() ne serait pas exécuté, et l'application pourrait continuerait de tourner...

En fait pour gérer ce cas extrême il faut utiliser un try/finally :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
	try {
		JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
		Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
	} finally {
		System.exit(1);
	}

Maintenant il y a deux point qui me gène dans ton code :

• Les 3 blocs de traitement des exceptions identique !
• Le fait que tu traites des Errors directement dans ton code.

Les Errors correspondent à des problèmes graves, et ne devrait pas vraiment être traitées...

Si tu es en Java 5.0 il est préférables d'utiliser les UncaughtExceptionHandler, qui te permettent de traiter les exceptions qui ne sont pas traitées :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
	Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
		@Override
		public void uncaughtException(Thread t, Throwable ex) {
			try {
				JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
				Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
			} finally {
				System.exit(1);
			}
		}
	});

a++

[Auteur]

Dans 99% des cas le System.gc() est contre-productif et peut engendrer de mauvaise performance... en plus d'être inutile !

C'est le cas ici car le GC va faire tout son possible pour libérer la mémoire avant de remonter une OutOfMemoryError.
Et à la fin de l'application la JVM libère toute la mémoire d'un bloc (ce qui est bien plus performant).

ok donc je supprime l'appel à System.gc()

Le exit() suffit amplement pour fermer l'application et tous ses éléments graphiques. Il me semble toutefois qu'on utilise en général un code de retour positif, mais c'est un détail...

Maintenant il est peut-être préférable de fermer explicitement certaines ressources qui pourrait se retrouver bloquer pendant un certain temps (comme une connexion réseau par exemple), mais il n'y a pas de problème pour tout ce qui concerne l'interface utilisateur...

Justement mon application créé 2 thread. Ils seront détruits lors de l'appel de exit() ?
Par ailleurs, si j'ai une connexion réseau et qu'une erreur comme celle-ci se produit, sera-t-elle fermée lors de l'appel de exit() ?

Maintenant si petit à petit ton application approche des 64Mo d'utilisation réelles, alors tu peux en effet rencontrer des problèmes à nouveau jusque dans le code de traitement de ton exception (par exemple car il n'y a toujours pas assez de mémoire pour le JOptionPane). Cela peut être problématique car alors le exit() ne serait pas exécuté, et l'application pourrait continuerait de tourner...

En fait pour gérer ce cas extrême il faut utiliser un try/finally :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
	try {
		JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
		Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
	} finally {
		System.exit(1);
	}

Les Errors correspondent à des problèmes graves, et ne devrait pas vraiment être traitées...

Si tu es en Java 5.0 il est préférables d'utiliser les UncaughtExceptionHandler, qui te permettent de traiter les exceptions qui ne sont pas traitées :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
	Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
		@Override
		public void uncaughtException(Thread t, Throwable ex) {
			try {
				JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
				Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
			} finally {
				System.exit(1);
			}
		}
	});

Il n'y a pas de catch() dans tes exemples


J'ai placé un finally{...} après le try et le exit est exécuté même si aucune erreur est levée... J'ai raté un truc ?

[Baptiste Wicht]

Justement mon application créé 2 thread. Ils seront détruits lors de l'appel de exit() ?

Oui, tout les threads sont détruits par exit().

Par ailleurs, si j'ai une connexion réseau et qu'une erreur comme celle-ci se produit, sera-t-elle fermée lors de l'appel de exit() ?

Non, c'est à toi de gérer ce cas-là, les ressources ne sont pas automatiquement fermées.

Il n'y a pas de catch() dans tes exemples

J'ai placé un finally{...} après le try et le exit est exécuté même si aucune erreur est levée... J'ai raté un truc ?

Tu n'en a pas pas besoin.

Il s'agit d'un try/finally. Ce qui va dire que ton exit(-1) sera éxécuté même si une erreur survient dans le corps du try, dans cet exemple s'il n'y a plus assez de mémoire pour créer un nouvel objet et pour éxécuter JOptionPane, ton programme va quand même correctement quitter.

[Auteur]

J'aurai peut-être dû le dire dès le début
L'erreur "java.lang.OutOfMemoryError: Java heap space" se produit lorsque je remplis un JTextPane. Il arrive un moment où je ne peux plus écrire dans le composant car l'application ne dispose pas de mémoire suffisante.

Si tu es en Java 5.0 il est préférables d'utiliser les UncaughtExceptionHandler, qui te permettent de traiter les exceptions qui ne sont pas traitées :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
	Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
		@Override
		public void uncaughtException(Thread t, Throwable ex) {
			try {
				JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
				Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
			} finally {
				System.exit(1);
			}
		}
	});

Ce bout de code m'intéresse bien Mais est-t-il possible de filtrer les exceptions qui seront gérées par ce thread ?
En effet, la boite dialogue s'affiche et le programme quitte à la moindre exception levée ou non gérée (c'est le but me direz vous). Mais est-il possible de ne traiter que l'erreur Java Heap Space ?

[adiGuba]

Il doit être énorme ton JTextPane

Ce bout de code m'intéresse bien Mais est-t-il possible de filtrer les exceptions qui seront gérées par ce thread ?

Tu peux "thrower" l'exception pour la recatcher

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
	Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
		@Override
		public void uncaughtException(Thread t, Throwable ex) {
			try {
				throw ex;
			} catch(OutOfMemoryError e) {
				// traitement OutOfMemoryError
			} catch (Throwable t) {
				// Autre traitement
			}
		}
	});

Par contre les autres exceptions qui arrive ici sont des erreurs inattendus, donc il n'y a pas vraiment de raison que tu les ignores. Cela pourrait même être "dangereux" en générant de plus en plus d'erreurs incompréhensible...


a++