tkdmatze

lesen grosser

zur NOT

*püh*

manche lesen nur was sie wollen

Hast du dich denn bereits mit dem Konzept eines LayoutManagers befasst?

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

Das Hochwerfen ist immer dann sinnvoll, wenn das Objekt, in dem der Fehler provoziert wird, ein einfach gestricktes Objekt und das delegierende Objekt einen anderen Weg zum Ziel kennt.

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);

        }

    }

    }

}

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();


}

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

Wenn du den Sinn hinter einem solchen Konzept nicht wirklich verstehen willst, bitteschön.

der offensichtlich nicht weiss wovon er redet dummkommt, kontere ich

püh

Zugegeben, daß Beispiel hört sich etwas herbeigezogen an.

vor allem, weil das normale vorgehen beschreibst

....

(1) Dateireferenz erstellen

(2) Datei zum Schreiben öffnen

(3) Werte in Datei schreiben

(4) Datei schließen

....

schau mal in die java-api-src

glaub net, dass du versuchen willst, sun-programmierer davon zu überzeugen, das du recht hast :marine

Wenn du hier hingehen willst und bei jedem einzelnen Unterpunkt Fehler abfangen und darauf reagieren willst, wirst du ausser zu Fehlerbehandlung zu wenigen Dingen in deinem Programm kommen.

Und während in Villariba noch Fehler abgefangen werden wird in Villabacho bereits mit der Applikation Geld verdient.

quick and dirty heisst das, und ist nicht grade "gute" Programmierung

schnell geschrieben, das ist auch alles

Wenn du den Sinn hinter einem solchen Konzept nicht wirklich verstehen willst, bitteschön.

Und wenn dir meine Erklärung nicht ausreicht, vielleicht überzeugt dich eine dieser Abhandlungen:

: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

Und genau das ist eben nicht Sinn von Exception-Handling (und auch nicht der Sinn von OOP). Fehler sollen dort behandelt werden, wo es sinnvoll ist sie zu behandeln und darauf zu reagieren und eben nicht dort, wo sie entstehen. Sonst könnte man sich das gesamte Exception-Konzept schenken und wie zu den grauen Zeiten von C nur mit Return-Codes arbeiten.

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

Nein den kannte ich noch nicht, aber danke für den Hinweis... das erklärt so einiges

Ach ja und die Methode wirft nun auch keine Exception mehr. Fehlerausgabe/Korrektur erledige ich nun nur noch über die Klasse.

Ist das eigentlich vorteilhaft oder sollte man dies von der "Main" aus machen?

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) {}

}

//_

aber auch in java hat static nichts mit konstant zu tun

einfach die begriffe richtig sortieren

Konstante:

const $constant;

Privat && Statisch

private static $var

es ginge sogar

private static const

denn es hat alles verschiedene bedeutungen

private = nur in der klasse sichtbar

static = statisch, egal wie viele viele Objekte du initiierst, es wird nur einmal

der statische anteil geladen

const = konstant, unveränderbare variable

>>definieren und das ganze mit einem wert vorbelegen (final darf ich variablen >>glaub ich nicht definieren?).

>>richtig, final nnur für objekte und methoden

>>const $constant = new Object();

>>richtig?

hat ich noch nie vor

naja, also

das hier ist schon um klassen besser und bunter

http://www.mips.com/content/PressRoom/TechLibrary/WhitePapers/34k

wo bei mir eher das verständnis fehlt

-für die fehler behandlung(Data Hazards)

read-after-write (RAW),write-after-read (WAR),write-after-write (WAW)

finde da keinen guten text zu

und

-Multiplexer

von daher ist der Wiki- Link für mich viel zu oberflächlich

Moin Jungs und Mädels

Ja ich hab es geschafft, ich darf meinen Vortag halten über ein tolles Thema,

die Playstation 2, jeder der denkt, pah, ein spiele-computer, der irrt,

die technik in so einer playstation ist äussert komplex und der pc-technik zum teil weit vorraus

bei meinen recherchen kamen aber auch bei mir zum teil verständnis-schwierigleiten auf, wo ich jetzt ein bisschen auf euch hoffe

CPU : die sogenannte "Emotion Engine" ist ein MIPS - Prozessor

(Microprocessor without interlocked pipeline stages)

kann mir einer bitte erklären, wie ein MIPS - Prozessor im gegensatz zu einer normalen CPU funktioniert und wo die vorteile eines MIPS im gesamtkonzept der PS2 sind?, da steh ich etwas auf dem schlauch