Exceptions auslagern

[kingpin000]

Hallo,
ich würde gerne die Exceptions zu den Methoden, die ich in eine andere Klasse ausgelagert habe, mitdrüber nehmen, nur leider hab ich keine Ahnung was ich da beachten muss, damit meine main auf diese Exceptions wieder zugreifen kann.

Hab ihr Tipps für mich?

 

[Volvagia]

Definiere sie in einer eigenen Top-Level-Klasse.
Allerdings sollte vom Gebrauch eigener Exceptions eher Abstang genommen werden.

 

[kingpin000]

Und was ist mit den Try-Catch Anweisungen? Bleiben die in der main oder können die auch in der Methodenklasse verwendet werden?

 

[TryToHelp]

Wieso sollte davon abstand genommen werden? Wenn es Business-Exceptions sind, macht es sin, diese auch selber zu erstellen und zu verwenden und nicht irgendwelchen unpassenden standart Exceptions zu werfen.
so z.B. bei einer Abbuchung, wenn das Konto leer ist, macht es keinen sinn eine eine nullPointerException oder ioException zu werfen, sondern eine eigene kontoLeerException ;-)

 

[SlaterB]

> Und was ist mit den Try-Catch Anweisungen? Bleiben die in der main oder können die auch in der Methodenklasse verwendet werden?

try/catch steht wie jede Codezeile grundsätzlich da wo sie sinnvoll ist,
verschieben bzw. bleiben sind da fragwürdige Begriffe, denkbar ist natürlich vieles

 

[kingpin000]

> Und was ist mit den Try-Catch Anweisungen? Bleiben die in der main oder können die auch in der Methodenklasse verwendet werden?

try/catch steht wie jede Codezeile grundsätzlich da wo sie sinnvoll ist,
verschieben bzw. bleiben sind da fragwürdige Begriffe, denkbar ist natürlich vieles

Wie soll ich vorgehen, wenn ich die Exception schon vorher von der Methode prüfe lasse möchte, bevor das Ergebnis ans main zurück geschickt wird?

 

[tfa]

Wie soll ich vorgehen, wenn ich die Exception schon vorher von der Methode prüfe lasse möchte, bevor das Ergebnis ans main zurück geschickt wird?

Mit try und catch? Vielleicht gibst du mal ein kurzes Code-Beispiel, damit man sich das besser vorstellen kann.

 

[kingpin000]

@SuppressWarnings("serial")
class NotNaturalNumberException extends Exception
{
    public NotNaturalNumberException() {}    
    public NotNaturalNumberException(String s)
    {
        super(s);
    }
}

@SuppressWarnings("serial")
class ResultErrorException extends Exception
{
    public ResultErrorException() {}    
    public ResultErrorException(String s)
    {
        super(s);
    }
}


public class miniMathLib 
{
	
	public class MiniMath 
	{
		private double zahl;
		
		public boolean ganzZahl(double kommaZahl) throws NotNaturalNumberException
		{	
			try
			{
			zahl = kommaZahl;
			
			if (zahl/(int)zahl <= 1.0+1e-15 || zahl == 0.0)
				return true;
			throw new NotNaturalNumberException("keine natuerliche Zahl");
			}
			catch (NotNaturalNumberException exc)
			{
				System.out.println(exc.getMessage());
			}
		}
	
		public int fakultaet(double kommaZahl) throws ResultErrorException
		{
			try
			{
			zahl = kommaZahl;
			
			int fak = 1;
			int temp = 0;
			int overflow = 1;
			
			if (zahl < 0.0)
				throw new ResultErrorException("negative Zahlen nicht zulaessig");
						
			for (int i = 1; i<=(int)zahl; i++)
			{
				temp = fak;
				fak = fak*i;
				overflow = fak/i;
				if (temp != overflow)
					throw new ResultErrorException("Overflow! \n" +
							"Berechnung nur bis zur "+ (i-1) +".Fakultaet möglich");
			}
			return fak;
			}
			catch (ResultErrorException exc)
			{
				System.out.println(exc.getMessage());
			}
		}	
	}    	
}

 

[Volvagia]

Jetzt throwst du die Exception direkt ins catch. Wird nur nicht gehen, da die Methode nicht umbedingt etwas zurückgeben wird.

Wieso sollte davon abstand genommen werden? Wenn es Business-Exceptions sind, macht es sin, diese auch selber zu erstellen und zu verwenden und nicht irgendwelchen unpassenden standart Exceptions zu werfen.
so z.B. bei einer Abbuchung, wenn das Konto leer ist, macht es keinen sinn eine eine nullPointerException oder ioException zu werfen, sondern eine eigene kontoLeerException ;-)

Wäre das keine Steuerung von Programmcode? Falls man vorhat eine Datei zu schreiben wird ja auch vorher geprüft ob der Pfad und die Datei existiert und gegebenfalls angelegt, und nicht wild drauf losgeschrieben.

 

[SlaterB]

in derselben Methode zu werfen und zu catchen ist normalerweise unnötig, außer man möchte paar Ebenen von verschachtelten Schleifen oder so (relativ unsauber) überspringen,
zusammen mit throws an der Methode-Deklaration wird es endgültig unsinnig

man kann nicht beantworten was du wo wie machen musst, wenn nicht vorher klar ist, was fachlich passieren soll,
wofür willst du die Exceptions einsetzen, oder ist es ein Selbstzweck, 'soll drin sein irgendwie..'?

der normalste Weg ist throws an der Methoden-Deklaration und natürlich ein Werten in der Methode, das heißt ja das 'throws',
ein Hinweis das Exceptions geworfen werden

ergo findet das try/catch außerhalb statt, aber nicht zum Spass, sondern weil es Sinn ergeben soll,
wenn nur ein Aufrufer da ist, der direkt abfängt und ausgibt und sonst nichts passiert,
dann könnte man praktisch auch auf die Exception verzichten, gleich im Fehlerfall etwas ausgeben und die Methode beenden,
kommt fast auf dasselbe hinaus,
freilich dann noch die Frage des Rückgabewertes, insofern Exception schon besser,
dann weiß der Aufrufer vom Fehler und reagiert eben doch anders, verwendet nicht den nicht vorhandenen Rückgabewert

also kurzer Sinn: try/catch aus der Methode raus, zum Aufrufer


-------

@Volvagia
> Wäre das keine Steuerung von Programmcode? Falls man vorhat eine Datei zu schreiben wird ja auch vorher geprüft ob der Pfad und die Datei existiert und gegebenfalls angelegt, und nicht wild drauf losgeschrieben.

Exceptions sind (edit: auch) Steuerung von Programmcode, richtig

und was spielt die Datei für eine Rolle? möchtest du mit IOException oder zumindest FileNotFoundException jetzt auch noch API-Exceptions obsolet machen (nach eigenen Exception-Klassen)?

vieles geht ohne Exceptions, manche Programme oder tausende Zeilen Code hintereinander kommen ohne aus,
aber nicht alles läßt sich immer prüfen, immer gleich passend reagieren

 

[kingpin000]

man kann nicht beantworten was du wo wie machen musst, wenn nicht vorher klar ist, was fachlich passieren soll,
wofür willst du die Exceptions einsetzen, oder ist es ein Selbstzweck, 'soll drin sein irgendwie..'?

Ich halt noch Anfänger und soll gemäß der Uni-Aufgabe die Exceptions in der Nebendatei definieren, aber von der main thrown lassen.

 

[TryToHelp]

Wäre das keine Steuerung von Programmcode? Falls man vorhat eine Datei zu schreiben wird ja auch vorher geprüft ob der Pfad und die Datei existiert und gegebenfalls angelegt, und nicht wild drauf losgeschrieben.

Ähm ja man kann das schon alles Testen, aber so verlagerst du die logik, und klar könnte ich boolen überweisung(betrag, konto) machen, aber wenn es mehr gründe für nicht funktionierende überweisung gibt, ist der boolean schon doof, jetzt kann ich natürlich int überweisung(betrag, konto) machen und dann mittels des rückgabewertes den fehler codieren, oder halt durch exceptions, das fehlverhalten senden, so z.B. kontoLeerException und kundeNichtVorhandenException,... was dann einfach zu händeln ist, alle erben von z.B. überweisungsException, nun kann mein Programm auf den Fehler eingehen und gesondert weioterarbeiten oder einfach bei allen überweisungsException sagen ist gescheitert,...

 

[SlaterB]

@kingpin000
exakt interpretieren kann man das leider nicht und du solltest versuchen, mit wem auch immer erst das Verständnis von Aufgaben abzuklären,
aber das ist in einem solchen Fall von außen natürlich leicht gesagt, ein kleines Dilemma

beim bester Tipp ist wie zuvor also try/catch beim Aufrufer, in der main-Methode

 

[kingpin000]

Schau dir mal selber das Aufgabenblatt an. Ich hänge an Aufgabe 2.2 fest...

 

[Volvagia]

Sollst du es in der Main throwen, in die Main throwen oder sollst du es über die Main throwen? Weiß nicht ob die Bezeichnungen so richtig sind, macht aber einen Unterschied.
Falls du es über die Main throwst fügst du einfach

throws NotNaturalNumberException

hinzu und entfernst die tries aus den Methoden. Falls du es in der Main throwst fügst du ein

throw new NotNaturalNumberException

dort hin, von wo aus es gethrowt werden soll. Falls du es in die Main throwen sollst so wie SlaterB sagte.

Ähm ja man kann das schon alles Testen, aber so verlagerst du die logik, und klar könnte ich boolen überweisung(betrag, konto) machen, aber wenn es mehr gründe für nicht funktionierende überweisung gibt, ist der boolean schon doof, jetzt kann ich natürlich int überweisung(betrag, konto) machen und dann mittels des rückgabewertes den fehler codieren, oder halt durch exceptions, das fehlverhalten senden, so z.B. kontoLeerException und kundeNichtVorhandenException,... was dann einfach zu händeln ist, alle erben von z.B. überweisungsException, nun kann mein Programm auf den Fehler eingehen und gesondert weioterarbeiten oder einfach bei allen überweisungsException sagen ist gescheitert,...

Das stimmt natürlich. Ich wollte mit dem Text keine Kritik ausüben, ich vergleiche nur meine Denkweise gerne mit anderen um Dinge aus unterschiedlichen Perspektiven zu sehen.

 

[SlaterB]

@kingpin000
die richtige Verwendung von Exceptions sollte bereits in Aufgabe 1.3 funktionieren,
in 2 sollst du nur die Methoden in eine andere Klasse schieben und die Definition der Exceptionklassen auch,
das ändert am Code innerhalb der Methoden gar nichts und beim Aufrufer der Methoden maximal das Objekt, an dem aufgerufen wird, zum try/catch ändert sich nichts,

wie sieht 1.3 bei dir aus?