tkdmatze

lesen grosser zur NOT *püh* manche lesen nur was sie wollen

zur Not gibts ja noch null mit hilfe von GUI-Editoren kann man dann ein Layout erstellen mit absoluten Positionen, allerdings reagieren die nicht mehr dynamisch auf veränderungen der fenstergrösse

klingt als ob man sich drauf einigen könnte allerdings gehts bei dir darum, die nachricht weiterzugeben, nicht das obejct an sich @ar-sch.de dein vorgehen ist sicher richtig, wobei du es zwar nach oben (Exception) wirfst, aber ableitest, etwas, was hier nicht zur rede kam wenn man den ansatz so machst und für die möglichen Fehlern eine entsprechende Exception-Klasse schreibt, kann man dort auch -Fehlerausgabe und -Fehlerbehandlung in der fehlerklasse implementieren, was du "nach oben" wirfst, ist aber nicht die Reine Exception, sondern halt eine Ableitung davon jedoch sehe ich nicht viel unterschied in public class Main{ public static void main(String[] args){ .... try{ liesTabelleBla(); }catch(Exception ex){ ex.gibFehlerAus(); } } } public class DBLeser { private Statement stmt; liesTabelleBla() throws DBLeserException { try { stmt.execute("SELECT * FROM tabelleBla WHERE id = 4711"); } catch (SQLException e) { throw new DBLeserException("Lesefehler: tabelleBla.", e); } } } } und public class Main{ public static void main(String[] args){ .... try{ liesTabelleBla(); }catch(Exception ex){ } } } public class DBLeser { private Statement stmt; liesTabelleBla() throws Exception { try { stmt.execute("SELECT * FROM tabelleBla WHERE id = 4711"); } catch (SQLException e) { gibFehlerAus(); } } } } in beiden Fällen sind alle infos da, dein Vorgehen wäre dann anders, (hast vllt schlechtes beispiel genommen) wenn eine Heirarchie dahintersteht, die mehr als 2 Stufen hat zB Main>>Eingabe>>SQL-Eingabe>>Bauinfos>>liesTabelleBla Main>>Verarbeitung>>Aktualisiere>>Bauinfos>>liesTabelleBla wo ein Fehler in liesTabelleBla, nicht wüsste, ob er grad in Eingabe passiert ist, oder einem anderen Modul(Verarbeitung)

nehmen wir mal an, eingabe so wie es oft ewähnt wurde class Eingabe{ File datei; Eingabe(Sting dateiname); boolean open(); String[] leseWerte(); boolean close(); } in der Main dann Class Main[ Eingabe myEin = new Eingabe("test.txt"); if(myEin.open()){ String[] werte = myEin.leseWerte(); myEin.close(); } werfe ich den Fehler nach oben, fehlen mir eventuelle Umgebungsvariablen, die in Eingabe da wären, ausserdem kann man eigene Fehlerklassen definieren, zB "Datei hat nicht die entsprechene länge", wo der vergleichswert ("tatsächliche länge") beim hochthrowen verloren geht, oder mitgegeben werden muss eine Fehlermeldung sollte so aussagekräftig wie möglich sein, denn dann ist es einfacher sie zu beheben so wäre eine "zuwenigezeilenException" mit den argumenten "int soll" und "int ist" ausgestattet eine "DateiNichtVorhanden" bzw "DateiNichtLesbar" mit den Argumenten dateiname ausgestattet will man das alles nach oben werfen, und das Project nur gross genug wird die main unlesbar, da eine Ewig lange fehlerbehandlung dort ausgeführt wird normalerweise sollte ja nicht erkennbar sein, das ein Fehler aufgetreten ist, sondern Welcher, Wo und Warum

der nick sagt alles ich denke nur, wenn es antworten gibt, dann sollten die auch richtig sein und wenn mir ein FI mit der offensichtlich nicht weiss wovon er redet dummkommt, kontere ich püh

vor allem, weil das normale vorgehen beschreibst schau mal in die java-api-src glaub net, dass du versuchen willst, sun-programmierer davon zu überzeugen, das du recht hast :marine quick and dirty heisst das, und ist nicht grade "gute" Programmierung schnell geschrieben, das ist auch alles :marine eigentor kleiner c++ gibts kein hoch-throwen , c# laut dem tut auch net :confused: der stil, bei java einfach alles "hochzuthrowen" hat sich nur eingebürgert, weils so schön einfach ist mit ordentlichem programmieren hat das nicht viel zu tun, P.S.:aber wer sagt, das FIs programmieren können, bin gott sei dank keiner

nenn mir ein Beispiel, wo es sinnvoller ist, fehler nach oben zu werfen als sie zu behandeln los eins nur ich warte..........

lol, ich hab den quote-tag vergessen carnie schrieb das vorgehen ist doch folgendes while(!abbruch){ temp = berechneNächsteGeneration(feld); trageTempInsFeldEin(); } wichtig ist, das man die nächste generation zwischenspeichert

da liegt der Sinn der OOP, alles was zum Thema gehört in einer Klasse zu lösen Fehler dort behandeln, wo sie entstehen, gehört für mich eigentlich auch dazu

Ist nicht ganz so trivial wie ich auch erst dachte. wo ist das problem?

public ResultSet querry(String statement) { try{ Statement stmt = conn.createStatement(); ResultSet result = stmt.executeQuery(statement); return result; } catch (Exception e) { System.out.println("Fehler "+e); } return null; } besserer Stil wer catched, muss net throwen Variablen so lokal wie möglich anlegen

lol fw = new BufferedWriter(new FileWriter( "fabend.txt" ,false)); fw.write(a); fw.newLine(); fw.write(;

new FileWriter( "fabend.txt" ,true)); == append true also "anhängen an das was vorher war" dann entsprechend false setzen new FileWriter( "fabend.txt" ,false));

zeile spalte hä?

// Speichern der Überstunden Heute BufferedWriter fw = null; try { fw = new BufferedWriter(new FileWriter( "fabend.txt" ,true)); fw.write(mg); fw.newLine(); } catch ( IOException e ) { System.out.println( "Konnte Datei nicht erstellen" ); } finally { try { if ( fw != null ) fw.close(); } catch (IOException e) {} } //_