[JAVA] Bases du branchement conditionnel et du retour

J'étais inquiet car une erreur se produirait si je ne revenais pas de la mystérieuse branche conditionnelle

Quand j'écrivais du code avec une instruction if, j'étais souvent en colère contre Eclipse disant "Il n'y a pas de retour !!". Mais je ne sais pas pourquoi. .. ..

Afin de penser sous une forme plus primitive, j'ai écrit une méthode qui renvoie la plus grande lorsque deux arguments de type int sont passés (c'est un coup en utilisant la fonction max, mais j'ai expérimenté un exemple facile à comprendre. Car je voulais).

//Code 1

public class BiggerNumber {

	public static void main(String[] args) {
		//TODO talon de méthode généré automatiquement
		System.out.println(returnBiggerNumber(250,500));
	}

	public static int returnBiggerNumber(int num1,int num2) {
		if (num1 < num2) {
			return num2;
		}else if (num1> num2 ) {
			return num1;
		}else if (num1 == num2) {
			return num1;
		}else {             //← Ceci!
			return num1;
		}
	}
}

C'était le dernier autre que je ne pouvais pas comprendre. Si vous n'écrivez pas ceci, vous obtiendrez une erreur de compilation. .. ..

Pour cette méthode très simple, il n'y a que trois branches possibles.

1. num1 est plus grand
2. num2 est plus grand
3. num1 et num2 sont égaux

Théoriquement, cela devrait couvrir toutes les possibilités. .. .. Je devrais être capable de renvoyer n'importe quel numéro dans l'argument Y a-t-il une autre possibilité? J'étais inquiet.

Cause et comment écrire sur cette base

Quand j'ai demandé à un senior avec une longue histoire de Java sur la cause de l'erreur, ** "Le compilateur ne peut pas déterminer si toutes les branches conditionnelles sont écrites sans exception. Par conséquent, même s'il s'agit d'une branche conditionnelle qui ne peut pas être réellement atteinte, il est nécessaire de l'écrire formellement. 』** est ce qu'ils ont dit.

"Je vois!"

Si tel est le cas, la seule possibilité de branchement autre que <,> est ==. Il peut ne pas être nécessaire d'écrire l'expression conditionnelle de ==. Donc (je) la première chose qui me vient à l'esprit est la suivante.

//Code 2

	public static int returnBiggerNumber(int num1,int num2) {
		if (num1 < num2) {
			return num2;
		}else if (num1> num2 ) {
			return num1;
		}else {
			return num1;
		}
	}

Ou il y a aussi ça.

//Code 3

	public static int returnBiggerNumber(int num1,int num2) {
		if (num1 < num2) {
			return num2;
		}else if (num1> num2 ) {
			return num1;
		}
		return num1;
	}

Cela semble un peu étrange, mais c'est aussi efficace. Est-ce une question de goût?

//Code 4

	public static int returnBiggerNumber(int num1,int num2) {
		if (num1 < num2) {
			return num2;
		}else if (num1> num2 ) {
			return num1;
		}else if (num1 == num2) {

		}
		return num1;
	}

Confus avec le commutateur {case} de Swift (à moitié comme une note personnelle)

En premier lieu, il ne devrait y avoir aucun problème car on peut revenir pour tous les motifs! J'étais convaincu que cela était dû aux ** règles de déclaration de commutation de Swift **.

C'est ça. ** "Existe-t-il une clause case qui couvre toutes les valeurs possibles du type de valeur donné au commutateur? La clause par défaut doit exister. 』** (* Au fait, ce n'est pas nécessaire en Java, et ce n'est pas nécessaire dans l'instruction if même avec le même Swift)

Non, ** Ceci est une histoire qui n'a rien à voir avec la valeur de retour. .. .. ** J'ai eu un malentendu.

Qu'il s'agisse d'une instruction Java switch, d'une instruction swift if ou d'une instruction switch, Si c'est une fonction / méthode qui renvoie une valeur de retour, il est nécessaire de renvoyer (renvoyer) toutes les valeurs.

Juste au cas où, par exemple

public int returnTest(int i) {
	switch (i) {
	case 1:
		return 1;
	case 2:
		return 2;
	case 3:
		return 3;
　　　　　//De cette façon, vous devez écrire return en dehors du bloc par défaut ou switch.
　　　　　//En Swift, cette méthode d'écriture provoque une erreur, alors écrivez-la en dehors du bloc de commutation.
	default:
		return 4;
	}
}

Il s'agit d'une règle courante, mais il semble qu'elle ne puisse pas être organisée en raison d'une connaissance à moitié terminée des règles spécifiques à la langue.

Donc, j'étais convaincu pour le moment, mais j'apprécierais si vous pouviez commenter si vous avez des tsukkomi ou + α.