Ascii-Reader die dritte :)

  • Hi!

    Nachdem ich die ersten zwei Übungsrunden in "Einführung in die Programmierung" auf der TU mehr oder weniger leicht geschafft habe (ua. dank eurer Hilfe :wave:) bin ich bei der dritten Aufgabe nun mittel bis sehr am verzweifeln. Es geht ungefähr um das selbe, wie bei den ersten zwei Beispielen: Man muss ein ASCII-Bild einlesen, überprüfen, ob Höhe und Breite 100 nicht überschreitet und ob alle Zeilen gleich lang sein. Das Bild soll, wenn die Angaben korrekt sind, mitsamt der Zeichen- und Zeilenanzahl in ein Objekt der Klasse AsciiImage gespeichert werden. Hierbei sollen die Höhe und Breite nur einmal definiert werden können, und das Bild nur mit einer Methode addLine() vergrößert werden können. Ich hab das ganze jetzt also so geschrieben, wie ich vermute dass es richtig ist und... der Compiler wirft mir 29(!) Fehler aus :wein:
    Da ich vermute, dass viele davon Folgefehler aus den ersten sind, ich aber mit den ersten absolut nichts anfangen kann, bzw nicht weiß, was daran falsch sein könnte, bitte ich euch ein weiteres mal um Hilfe :rolleyes:.

    Hier mal main AsciiReader:

    Und hier die Klasse AsciiImage:

    Ich habs schon durchgesehen, und mit den Folien aus der Vorlesung verglichen, kann aber keine groben Fehler finden. Bei public String getBild() etwa meint der Compiler, dass es sich um einen "illegal start of expression" handelt. Aber ich weiß ehrlich nicht, was dran falsch ist, bzw was ich auch nur ändern könnte..

    Würde mich über jegliche Hilfe enorm freuen,

    L.G.: emptyvi :)

  • Edith meint: Hab eine verkehrte Klammer entdeckt, die ca. die Hälfte aller Fehler verursacht hat *schweiß abwisch* ^^
    Die anderen Fehler wie etwa int groß geschrieben, int als string ausgegebn, Scanner nichts mitgegeben, Tippfehler in Variablennamen etc weitgehend ausgemerzt.. Mal schauen, ob es so arbeitet wie es soll :)

  • Nein, da uns gesagt wurde, dass wir das nicht tun sollen, damit wir lernen, sich nicht auf Autovervollständigen-Funktionen etc. zu verlassen, sondern den Code selber kennen. :/

    Ich habe es aber, nachdem mir der Knopf schließlich doch noch aufgegangen ist, trotzdem geschafft :))

    Der Vollständigkeit halber hier mal der Code:

    AsciiReader.java:

    import java.util.Scanner;


    AsciiImage.java:

    L.G.: emptyvi :thumb:

  • Nein, da uns gesagt wurde, dass wir das nicht tun sollen, damit wir lernen, sich nicht auf Autovervollständigen-Funktionen etc. zu verlassen, sondern den Code selber kennen. :/

    So ein Schwachsinn!

    Bei jedem halbwegs vernünftigen Editor merkt man so etwas sofort. Es muss ja noch nichtmal eine komplette IDE sein. Aber wenn man sich wundert, warum der Editor die Einrückung komisch macht, dann wird man sehr bald auf solche Sachen draufkommen ;)

  • Nein, da uns gesagt wurde, dass wir das nicht tun sollen, damit wir lernen, sich nicht auf Autovervollständigen-Funktionen etc. zu verlassen, sondern den Code selber kennen. :/

    Mm und wo genau ist jetzt der Unterschied ob dich hier im Forum wer auf Syntaxfehler aufmerksam macht oder dies gleich der Editor übernimmt? :confused: ;)

  • Nein, da uns gesagt wurde, dass wir das nicht tun sollen, damit wir lernen, sich nicht auf Autovervollständigen-Funktionen etc. zu verlassen, sondern den Code selber kennen. :/

    Das war aus meiner Erfahrung auch ein guter Rat. Was Du falsch gemacht hast ist ein ganz typischer Anfaengerfehler: Du hast die Fehlermeldungen ignoriert.

    Wenn ich versuche deinen Code zu kompilieren, dann sagt mir der Compiler ziemlich detailiert, was damit nicht stimmt:

    Also wenn da in der ersten Zeile steht "The constructor Scanner() is undefined", dann schaust Du Dir halt mal als erstes in der Doku die Klasse Scanner an. Da siehst du dann auch das der Compiler dich nicht belogen hat: Da gibt es keinen Konstruktor ohne Argumente.

    Wenn da in der Zweiten Zeile steht, das der Type Scanner keine Methode Next() hat, na dann wird das schon stimmen. Wieder in der Doku nachschauen und fertig.

    Wenn Dein Programm dann syntaktisch korrekt ist, aber es zur Laufzeit einen Fehler gibt, dann bekommst Du meist eine sogenannte Stacktrace zurueck: Da siehst Du dann den Programmfluss, bei dem der Fehler aufgetreten ist. Und zwar huebsch mit den Namen der Klassen und Methoden, die da aufgerufen wurden. D.h. wenn Du als Fehlermeldung sowas bekommst:

    Code
    Exception in thread "main" java.lang.NullPointerException
    	at MyTest.run(MyTest.java:7)
    	at MyTest.main(MyTest.java:11)

    Dann gehst Du von oben nach unten duch die Zeilen, bis Du zu der ersten Methode kommst, die zu deinem eigenen Code gehoert. Dann weisst du auch ganz genau, wo da der Fehler ist.

    Wenn Du nicht weisst was eine NullPointerException ist => Doku schauen oder hier nachfragen.

    Wenn dein Programm keine Fehler wirft, aber sich nicht so verhält, wie du es geplant hast: einfach mal den Programmfluss durchgehen und z.b. mit System.out.println die Werte von einzelnen Variablen ausgeben. Dann siehst du auch gleich, wo was schiefgelaufen ist.


    Oh, und ganz wichtig: Ich wuerde niemals wieder so viel Code schreiben, wie du es hier getan hast, ohne zwischendurch zu kompilieren und zu schauen, ob alles bis jetzt passt.

    Also Du haettest z.b. bei diesem Stand vom AsciiReader das erste mal kompilieren sollen:

    Weil kompilieren kostet meisten nichts, und Fehler suchen schon.


    Zusammengefasst: Debuggen muss man aktiv, nicht passiv. Stundenlang auf den Code schauen und raten ist der falsche weg. Feedback erzeugen und interpretieren ist viel gescheiter.

Jetzt mitmachen!

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