try-catch non dà risultato sperato.

[francesco51]

Ho scritto questo codice per fare un mio esercizio. Il risultato non è quello sperato nonostante eclipse non mi dà errori.
Non voglio la soluzione, ma che qualcuno mi fa ragionare per capire dove sbaglio.
grazie.

import java.util.Scanner;

public class DomandaRisposta {
	public static void main(String[] args) {
		Scanner scan = new Scanner(System.in);
		String stringa = "";
		System.out.println("Quanto ti piace la nutella?\n"
				+ "Le possibili risposte sono: \n" + "1) tantissimo\n"
				+ "2) tanto\n" + "3) abbastanza\n" + "4) poco\n"
				+ " Per terminare il programma digita la parola \"Fine\"");
		while (!(stringa = scan.next()).equals("fine")) {
			System.out.println("Hai digitato la parola: "
					+ stringa.toUpperCase() + "!");
			try {
				verificaParola(stringa);
			} catch (Exception ex) {
				ex.printStackTrace();
			}
		}
		System.out.println("Fine programma!");
	}


	private static void verificaParola(String stringa) {
if (stringa == "tantissimo") {
			System.out.println("Golosone/a, non ti sembra stai esagerando?");
		} else if (stringa == "tanto") {
			System.out.println("Golosone/a, diminuisci la nutella.");
		} else if (stringa == "abbastanza") {
			System.out.println("Sei nella norma!");
		} else if (stringa == "poco") {
			System.out.println("Fai bene, troppa nutella fà male!");
		}
	}
}

[francesco.muia]

Prima cosa l'uguaglianza degli oggetti si testa con il metodo equals e non == quind stringa.equals(".....").
Seconda cosa il blocco try e catch si potrebbe ometter in quanto il metodo verificaParala non solleva nessun tipo di checked exception.

[andbin]

Il risultato non è quello sperato

verificaParola non dichiara eccezioni "checked" (quindi da lì non possono uscire). Tecnicamente possono sempre uscire eccezioni unchecked ma in verificaParola non c'è nulla che ragionevolmente possa causare eccezioni unchecked. Quindi il try-catch nel main non serve a niente.

Comunque in verificaParola confronti le stringhe con ==. Questo è sbagliato concettualmente, perché non avrai mai alcuna di quelle condizioni "true", anche se inserisci a runtime una di quelle parole!

[francesco51]

perfetto ,ora funziona..grazie
certo che alcune volte sono piccolezze che però comportano il mal funzionamento...

[valia]

in realtà non sono piccolezze:

1. equals è definito in Object ed è richiesto venga implementato per il confronto tra oggetti.
In generale == controlla i riferimenti. Se non fai implementazioni, equals resta il confronto tra riferimenti. Se sei interessato a confronti, controlla sempre che ci sia equals implementato. Il confronto tra stringhe è fatto già da java.lang.String.
La prima volta ci sta l'errore, l'ho fatto pure io. Quando ho riletto bene il libro da cui stavo studiando, mi sono accorta che questo concetto è specificato a caratteri cubitali quando si presentano gli operatori di confronto (primi capitoli del libro).
2. la gestione delle eccezioni. Se non hai affrontato ancora l'argomento, l'errore ci sta.
Se l'argomento lo hai già affrontato, ti manca qualche pezzo e ti consiglio di rivederlo.
La differenza tra eccezioni checked e unchecked la sai? Quando e perché si usa una e quando e perché si usa l'altra?

Fissa bene questi concetti adesso, non pensare che siano piccolezze

[francesco51]

per unchecked exception ci si riferisce alle RuntimeException e le sue sottoclassi(ArithmeticException,NullpointerExcepti on). Per tutte le altre parliamo di checked exception(eccezioni controllate).
comunque grazie,rivedrò il tutto...
Sai poi che c'è? che comunque sono tante le cose e molte cose sfuggono...per questo bisogna rileggerle spesso al fine poi di fissare bene i concetti....

[andbin]

per unchecked exception ci si riferisce alle RuntimeException e le sue sottoclassi

Sì.

Per tutte le altre parliamo di checked exception(eccezioni controllate).

Sì, salvo il ramo degli Error (deriva da Throwable) che tecnicamente sono "unchecked" (non si è obbligati a dichiararle/gestirle) ma concettualmente sono errori "gravi" che generalmente non vengono mai catturati esplicitamente se non per casi particolari/estremi.

[francesco51]

quindi per error mi parli di VitualMachineError e sottoclassi?

[valia]

io le ho fissate con un po' di esperienza lo ammetto, ma all'esperienza ho aggiunto una seconda lettura al libro, giusto perché avevo una migliore consapevolezza di quello che succedeva.

Error si riferisce a qualcosa di esterno al programma, che non puoi prevedere e non è detto che puoi gestire.
Runtime si riferisce a qualcosa relativo al programma, in genere un errore logico oppure un uso improprio delle API.

unchecked si usa per dire "visto che non sono prevedibili, non ti obbligo ad usare try/catch e non ti obbligo a prevedere situazioni di gestione degli stessi".

[andbin]

quindi per error mi parli di VitualMachineError e sottoclassi?

Sotto Error (direttamente o non) ci sono eccezioni tipo: OutOfMemoryError, StackOverflowError, ExceptionInInitializerError, NoClassDefFoundError, ecc...

Se si ottengono a runtime cose del genere, è parecchio improbabile che l'applicazione possa continuare correttamente e/o "recuperare" la normalità per procedere. Queste comunque sono cose che "non dovrebbero" mai succedere. Se succedono è probabilmente causa di configurazioni errate (es. jvm lanciata con heap-space insufficiente, jar in classpath errati che mancano di classi/metodi necessari, ecc...).