• Hi! :)

    Ich spiele mich gerade mit einem totalst rudimentären SQL-Parser herum.

    Bei SQL kann man z. B. folgendes programmieren: SELECT a FROM b WHERE c = "uvw\"xyz"

    So einen String soll mein Parser dann beherrschen können. Also mit diesem escapten Anführungszeichen.

    Jetzt bin ich grad am Tokenizer dran, der solche Strings erkennen soll. Da würd ich nun gern testen, ob das OK ist, was ich bislang programmiert haben.

    Aber wie definiert man in Java so einen String richtig? Mein Versuch mit einem Test-String:

    String sql = 'a>=b"c\"d"';

    Aber das klappt nicht. Bekomme ich nur jede Menge Fehler:


    Wie macht man denn das richtig in Java? Bin leider noch Anfänger in Java.

  • Strings sind in Java immer von Double Quotes (") eingeschlossen. Damit ein String Double Quotes enthalten kann, musst du die jeweils escapen. Den Backslash musst du natürlich auch escapen. Das wird dann etwa so ausschauen:

    PHP
    String sql = "a>=b\"c\\\"d\"";


    EDIT: Ha, schneller! :D

  • Hi! :)
    String sql = 'a>=b"c\"d"';

    Einfache Anführungszeichen markieren in Java Characterliterale. In Java beginnt jedes Stringliteral mit doppelten Anfühungszeichen. Alle doppelten Anführungszeichen, die im String vorkommen, müssen mit einem Backslash escaped werden. Backslashes werden ebenfalls mit einem Backslash escaped. So, wie das oben beim Select angegeben ist, ists richtig.
    Was deine sql-Variable eigentlich beinhalten soll, weiß ich allerdings nicht. Ich behaupte jetzt einfach mal, dass

    Code
    a>=b"c\"d"


    drin stehen soll.

    Escaped wäre das:

    Code
    Strings sql = "a>=b\"c\\\"d\"";


    (nicht überprüft).

    Sieh dir dazu bitte auch folgende Seite an: http://docs.oracle.com/javase/tutoria…characters.html
    Hier hast du ne Seite, wo du Zeug escaped datstellen lassen kannst (das obige scheint zu stimmen ^^): http://www.htmlescape.net/javaescape_tool.html

    l.g.

    P.S.: Falls du mit "Tokenizer" die Klasse StringTokenizer meinst.. die sollte so nicht mehr verwendet werden.

    Zitat


    StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead.

  • Ahh, so geht das. OK.
    Thanks!

    Zitat

    Falls du mit "Tokenizer" die Klasse StringTokenizer meinst.. die sollte so nicht mehr verwendet werden.


    Ich programmier mir im Parser einen eigenen Tokenizier. Dieses StringTokenizer kenn ich überhaupt nicht. :)

  • Ah.. noch eine kleine Anmerkung.. Es gibt eine kleine SQL-Datenbank.. hsqldb (wirst in SEPM wohl kennen lernen). Jedenfalls basiert die auf Java, und ist obendrein OpenSource.
    Den Sourcecode kannst du dir zum Beispiel hier anschauen: http://hsqldb.svn.sourceforge.net/viewvc/hsqldb/

  • Hm, wenn es hier schon die Java-Profis gibt ... mich würde interessieren, ob ich richtig in Java programmiere.

    Könntet ihr mal einen Code überfliegen? Gibts vielleicht irgendwas, was ich total falsch mache? D. h. dass ich hier in einem Stil programmiere, wie man das in Java überhaupt nicht macht???? Bin wirklich für jeden Hinweis dankbar! :)

    Hm ... falls man hier überhaupt einen Code reinposten kann ....
    Geht das hier in diesem Forum? Gibts dafür irgendwie ein eigenes Tag?

  • Hm, wenn es hier schon die Java-Profis gibt ... mich würde interessieren, ob ich richtig in Java programmiere.

    Könntet ihr mal einen Code überfliegen? Gibts vielleicht irgendwas, was ich total falsch mache? D. h. dass ich hier in einem Stil programmiere, wie man das in Java überhaupt nicht macht???? Bin wirklich für jeden Hinweis dankbar! :)

    Hm ... falls man hier überhaupt einen Code reinposten kann ....
    Geht das hier in diesem Forum? Gibts dafür irgendwie ein eigenes Tag?

    Klar, warum nicht. Tags für Code sind [ CODE ] und danach [ /CODE ] (ohne die Leerzeichen da drin.. die hab ich nur reingemacht, weil sonst das Forum hier ein Codefeld hinzeichnen würd ;)). Alternativ kannst du unten rechts auch einfach auf den Button "Go Advanced" gehen.. Dann siehst du oben im Editor zusätbliche Buttons - unter anderem ein #-Symbol. Das tut nichts anderes, als vor und hinter den markierten Code die beiden Tags zu setzen. Du kannst es auch mit dem Symbol "php" zwei weiter rechts probieren (entsrpicht den [ PHP ] und [ /PHP ] Tags). Dadurch wird der Code zusätzlich farbig gehighlighted und leichter lesbar (ist zwar eigentlich für PHP-Code, funktioniert mit Java aber auch einigermaßen).

    l.g.

  • OK.

    Also jetzt nicht schrecken. Das sind jetzt ein paar Klassen. Aber es geht hier wirklich nur um den Programmierstil. Z. B. ob man Exceptions anders handelt. Oder man man die Kommentare anders macht ... Solche Sachen.

    Code
    public class SqlOperatorException extends SqlPosException {
       /**
        * @param pos Position des ersten Operator-Zeichens im SQL-String.
        * @throws Exception
        */
       public SqlOperatorException (int pos) throws Exception {
          super ("SQL OPERATOR", pos);
       }
    }
    Code
    public interface IToken {
       public String getValue ();
    }
    Code
    public class SqlStringException extends SqlPosException {
       /**
        * @param pos Position vom öffnenden Anführungs-Zeichen im SQL-String.
        * @throws Exception
        */
       public SqlStringException (int pos) throws Exception {
          super ("SQL STRING", pos);
       }
    }


    Schaut hoffentlich nicht zu schlimm aus :confused:

    2 Mal editiert, zuletzt von Früchtemüsli (28. Oktober 2012 um 22:40)

  • OK.

    Also jetzt nicht schrecken. Das sind jetzt ein paar Klassen. Aber es geht hier wirklich nur um den Programmierstil. Z. B. ob man Exceptions anders handelt. Oder man man die Kommentare anders macht ... Solche Sachen.

    Schaut hoffentlich nicht zu schlimm aus :confused:

    Du kommentierst auf Deutsch und deine Exceptions können selber Exceptions werfen. Deine Methoden können Exception oder SqlStringException werfen. "throw new Exception("text")" ist ziemlich uncool. Es fehlen einige wichtige Kommentare (Kommentare zu den Klassen an sich zB.), andere sind imho zu kurz gehalten (Methodenkommentare).

  • Zitat

    deine Exceptions können selber Exceptions werfen


    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?

    Zitat

    Deine Methoden können Exception oder SqlStringException werfen.


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

    Zitat

    "throw new Exception("text")" ist ziemlich uncool


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

  • 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.

    "All through my life I've had this strange unaccountable feeling that something was going on in the world, something big, even sinister, and no one would tell me what it was."
    "No," said the old man, "that's just perfectly normal paranoia. Everyone in the Universe has that."

    😁😂😃😄😅😆😇😈😉😊😋😌😍😎😏😐😒😓😔😖😘😚😜😞😠😡😢😣😥😨😩😪😫😭😰😱😲😳😵😶😷

  • Zitat

    Damit ist gemeint, dass man keine rohen Exceptions werfen (und auch nicht fangen) sollte, sondern immer abgeleitete Klassen davon.

    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.

    Zitat

    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.

    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.

    Zitat

    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.

    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.

    Zitat

    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.

    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. Wenn so eine geworfen wird, weiß man dann, dass beim Errorhandling irgendwas schiefgelaufen ist.

    Zitat

    Wenn jetzt beim erstellen einer Exception eine andere geworfen würde, dann sieht der aufrufer nur diese und die eigentliche Exception geht verloren.

    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.

  • 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.

    "All through my life I've had this strange unaccountable feeling that something was going on in the world, something big, even sinister, and no one would tell me what it was."
    "No," said the old man, "that's just perfectly normal paranoia. Everyone in the Universe has that."

    😁😂😃😄😅😆😇😈😉😊😋😌😍😎😏😐😒😓😔😖😘😚😜😞😠😡😢😣😥😨😩😪😫😭😰😱😲😳😵😶😷

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!