Beiträge von sutupud

    Also einen Default-Errorhandler braucht man auf jeden Fall an der obersten Ebene. Für den Fall, dass man vergessen haben sollte, irgendwo eine Exception abzufangen. Und dort muss man dann natürlich auch ganz normale Exceptions abfangen.

    eigentlich ist es in java relativ schwierig zu 'vergessen' eine exception zu fangen.
    bis auf runtime exceptions müssen in java alle exeptions deklariert und behandelt werden, dass man da nichts vergisst schaut eigentlich schon der compiler.
    außer natürlich du deklarierst jede methode als "throws Exception", dann gibt es nichts was dich darauf hinweist.


    Hm, ich glaube ich verstehe, was du meinst. Die Differenzierbarkeit leidet darunter. Wenn ich diverse Pakete habe, kann ich deren Exceptions nicht mehr voneinander unterscheiden, richtig? Zumindest nicht anhand der Klasse, höchstens nur noch aufgrund der message. Ich habe mich bei unserem Professor erkundigt. Er meinte, man müsse grundsätzlich immer damit rechnen, dass irgendwo eine Exception geworfen werden könnte. Also auch in einer Exception-Klasse. Sofern ich im Konstruktor einer Exception-Klasse eine Exception werfe, habe ich dann nicht 2, sondern nur 1 Exception geworfen. Also ich glaube, man kann sehr wohl in einer Exception-Klasse eine Exception werfen. Nur wie du schon erwähnt hast, sollte man die wieder irgendwie speziell kennzeichnen. D. h. das sollte wieder eine spezielle Exception-Klasse sein, z. B. DefaultException.

    Natürlich ist immer mit einer Exception zu rechnen, und man kann Exceptions werfen wo man möchte. Du wirfst zwar nur eine Exception im im constructor, aber damit muss diese exception auch überall behandelt werden wo die exception erstellt wird, das hab ich gemeint mit zwei exceptions an stelle von einer.
    Du wirfst hier eine Exception im Konstruktor weil ein parameter falsch ist.
    Überleg dir mal, warum du das machst, ist der parameter wirklich so wichtig, dass es ein fehler ist wenn er falsch ist?

    • wenn nicht, dann braucht's hier keine exception, es würde reichen die error message entsprechend anzupassen
    • wenn ja, wofür brauchst du den wert? wenn du ihn für die weitere fehlerbehandlung brauchst, dann missbrauchst du hier wahrscheinlich eine exception als kontrollstruktur*.
      und wenn's wirklich ein gravierender programmierfehler ist, dann wär hier wahrscheinlich eine RuntimeException angepasst.

    *alles was du einer exception mitgibst soll eigentlich nur informativ sein, z.B. beim zurückverfolgen eines stacktraces. wenn du die informationen für was anderes als zur darstellung brauchst, dann ist das ein starkes zeichen dass du hier die exception für die programmlogik verwendest. So was macht man in anderen programmiersprachen (z.B. python), in java gilt das eher als "bad practice".
    Prinzipiell sollte eigentlich der typ der exception ausreichen um zu wissen wie man sie behandeln soll.


    Wenn so eine geworfen wird, weiß man dann, dass beim Errorhandling irgendwas schiefgelaufen ist. Man könnte versuchen, irgendwelche Daten zu retten, und die der DefaultException übergeben. Diese Klasse hätte dann ein String-Property. Vielleicht JSON-kodiert. Sodass sie generell alle Arten von Infos aufnehmen kann.Normalerweise sollte diese DefaultException sowieso nie geworfen werden. Das sollte sowieso nur eintreten, wenn man einen Programmierfehler gemacht hat.

    Wenn beim errorhandling was schief gegangen ist, dann ist das für mich auch ein zeichen für einen programmierfehler. Wie sollte den der aufrufer der methode so eine exception sinnvoll behandeln? Er weiß jetzt nur dass beim erstellen einer exception was schief gegangen ist. Darauf gibt es eigentlich nicht wirklich eine sinnvolle reaktion - außer eventuell loggen und weiterwerfen, und das ist meistens auch ein fall wo eine RuntimeException angebracht ist.

    Ich dreh das mal um:


    Was meinst denn damit? Wie wärs denn cooler? :)

    Damit ist gemeint, dass man keine rohen Exceptions werfen (und auch nicht fangen) sollte, sondern immer abgeleitete Klassen davon.
    Wenn du irgendwo eine "Exception" wirfst, dann zwingst du den aufrufer der methdoe dazu, alle Exceptions abzufangen oder weiter zu werfen, auch solche die man vielleicht überhaupt nicht behandeln möchte/kann. Exceptions müssen deklariert werden, damit man beim aufrufen einer methode schon weiß was möglicherweise schiefgehen könnte. Wenn da jetzt nur "throws Exception" steht, dann weiß man im prinzip gar nichts, außer über die efahrung des programmierers.


    Ist Java nicht dazu ausgelegt, unterschiedlichste Arten von Exceptions zu werfen?


    Genau, deshalb sollte man das auch immer so machen und unterschiedliche spezifische Exceptions verwenden, aber halt nicht "Exception".

    Womit wir bei

    Schaut das nur irgendwie nicht schön aus, oder kann das echte handfeste Probleme verursachen?
    Wie könnte man Kontrollen übergebener Parameter denn anders in Exception-Klassen machen in Java?


    wären. Das ist mehr als nur optisch unschön, das kann schon probleme machen. Wenn eine Exception im constructor wieder eine Exception werfen kann, dann muss ich überall wo ich sie instanziere auch die neue Exception behandeln oder werfen. Anstatt eine Exception zu behandeln hab ich also plötzlich zwei, von der eine nicht wirklich was mit dem ursprünglichen fehler zu tun hat.
    Exceptions sind zur fehlerbehandlung da, das heißt wenn ich eine werfe dann ist etwas schief gegangen auf das ich aufmerksam machen möchte. Wenn jetzt beim erstellen einer Exception eine andere geworfen würde, dann sieht der aufrufer nur diese und die eigentliche Exception geht verloren.

    du meinst du möchtest die credentials im code selbst drin haben und sicher stellen, dass wenn du den client verteilst niemand diese auslesen kann?
    geht eigentlich nicht.
    das einzige was du machen könntest, wäre benutzernamen und passwort irgendwie zu verschleiern und einen obfuscator zu verwenden damit es nicht ganz so leicht ist die daten auszulesen. aber letzendlich bringt das nicht wirklich viel, denn wenn du die verbindung zur datenbank herstellen möchtest musst du ja doch wieder username und passwort im cleartext angeben. und in java ist es ein kinderspiel so einen methodenaufruf abzufangen, z.B. mit hilfe des debuggers, oder durch bytecode manipulation mittels javassist oder aspectj und dergleichen, oder man ersetzt den jdbc driver durch eine eigenimplementierung die nichts anderes macht als die credentials auszugeben...
    clients die sich direkt mit einer datenbank verbinden sind ziemlich unüblich, normalerweise hat man einen business layer dazwischen mit einem geeigneten sicherheitskonzept das sicher stellt das jeder benutzer nur genau das machen kann was er darf.
    Klar, das könnte man das auch in der datenbank machen, für jeden benutzer einen datenbankuser anlegen mit entsprechenden berechtigungen, aber ob das wirklich eine gute idee ist...?

    sieh dir mal die beispiele in rfc1867 an:

    - die boundary wird jeweils durch -- eingeleitet
    - im content-type selbst werden diese nicht angeführt

    so funktioniert es:

    PHP
    String bound = Long.toString(System.currentTimeMillis());
            String boundary = "--" + bound;
            // ...
            con.setRequestProperty("Content-Type", "multipart/form-data; boundary=" + bound);

    was rauskommt sieht dann so aus:

    wenn du mehr - möchtest, dann werden die einfach zum teil von 'bound':

    PHP
    String bound = "---------------------------" + Long.toString(System.currentTimeMillis());
            String boundary = "--" + bound;
            // ...
            con.setRequestProperty("Content-Type", "multipart/form-data; boundary=" + bound);

    Vielleicht unterstützt dein Browser ja mit der aktuellen Konfiguration wirklich keine Cookies? Wie man Cookies aktiviert, hängt von deinem Browser ab, also sag mal, welchen Browser du benutzt.

    blödsinn. das würde nie zu einem server-error führen.
    die fehlermeldung sagt ganz klar, dass PHP kein schreibrecht auf /var/lib/php/session/ hat, weshalb es auch sinn machen würde die angegebenen zeilen

    Code
    session_save_path("/users/your/home/phpsess");
    session_set_cookie_params('3600', '/~USERNAME/');


    vor einem session_start() einzufügen, wobei natürlich /users/your/home/phpsess durch ein verzeichnis zu ersetzen ist auf das man schreibzugriff hat.
    ich schätze mal in der configuration.php wäre dieser eintrag gut aufgehoben, oder am anfang von session.php...

    na ja, grep arbeitet normalerweise zeile für zeile...
    mit "-z" kannst du es aber dazu zu bringen, das zu umgehen
    und im multiline-modus arbeitet man am besten mit pcre
    --> man pcrematching

    Code
    grep -Pzo '(?sm)(?<=TagA).*?(?=TagB)'

    damit sollte es eigentlich gehen...

    du brauchst hier den PCRE_DOTALL und den PCRE_MULTILINE modus - (?sm)
    die tags sollen ja nicht mit gecaptured werden, deshalb brauchst du hier lookbehind bzw. lookahad - (?<=...) (?=...)

    hallo Michi, soviel ich weiß sind Teile der Projekte auch immer wieder offen für solidarische Männer. Wenns Dir um den Job geht, dann frag doch einfach direkt an

    das ist doch nicht die antwort auf michi's eigentliche frage!
    die formulierung des inserates verstößt gegen die gleichberechtigungsgrundsätze - und keine sorge, bei der in aussicht gestellten bezahlung wird sich sicher niemand melden, der nicht "solidarisch" ist.

    das verzeichnis in dem deine klassen liegen musst du auch zum classpath hinzufügen... wenn's das akutelle verzeichnis ist:
    java -cp c:\weka\weka.jar;. AttributeSelectionTest

    bei java spricht man eigentlich nicht von 'linken'.
    du musst einfach beim ausführen auch die entsprechenden libraries im classpath haben, das war's dann schon. also z.b so was wie:
    java -classpath ./lib/foo.jar:./lib/bar.jar package.MainClass

    mir ist's tatsächlich mal am telefon passiert dass ich jemanden als "herr xxx" angesprochen habe, und er mich dann sofort korrigiert hat: "magister xxx"...
    sowas find ich echt schlimm...
    oder leute, die sich beschweren dass in einem online-formular ihr titel im drop-down menü nicht richtig vorkommt (zwischen "DI" und "Dipl.Ing" ist ja so ein großer unterschied). mein vorschlag: weg mit dem drop-down, soll doch jeder eintragen was ihm gefällt. oder gar nicht danach fragen.

    1) soweit ich weiß kann man auf eine lokalisierte version das language pack nicht installieren, das geht anscheinend nur auf die englische version.
    edit: bin mir nicht mehr ganz sicher, ob das bei windows 7 auch noch so ist... wo ich mal probleme damit hatte war glaube ich noch bei 'nem xp

    2) hab schon mal die msdnaa version für jemanden auf einem lenovo installiert, ging ohne probleme. Ich würd's ohne betriebssystem kaufen und die msdnaa version installieren... spart immerhin ein paar €
    (ich persönlich will meistens diese hersteller-tools so schnell wie möglich wieder los werden, nur unnötiger ballast)