PingPong-the Game by Developer-X

[cover1012]

Zur Umfrage: Hab' mal für "egal" gestimmt. Ist doch Definitonsgehangel. Wer hat schon sein erstes "Hello World" selbst per Hand geschrieben? Das wird irgendwo her kopiert (oder abgetippt), dann Compilieren, und wenn's geht ist gut. Was ich sagen will: Die Grenze zwischen "selbst schreiben" und "nicht selbst schreiben" ist fließend.....

Da stimme ich dir zu. Ich bin davon überzeugt, dass copy'n'paste eine wesentliche Methode auch in der professionellen Softwareentwicklung ist (warum das Rad neu erfinden?). Wichtig ist halt nur, dass man versteht, was man kopiert.

 

[Noctarius]

Da stimme ich dir zu. Ich bin davon überzeugt, dass copy'n'paste eine wesentliche Methode auch in der professionellen Softwareentwicklung ist (warum das Rad neu erfinden?). Wichtig ist halt nur, dass man versteht, was man kopiert.

Richtig und genau der letzte Satz ist der entscheidende Teil daran und das Ganze Copy&Paste (was ansich ja nichts schlimmes ist) abzustreiten ist peinlich. Zumal es absolut offensichlich ist.

 

[diggaa1984]

selbst wenn man sich an Tutorials orientiert, so übernimmt man eh meist ein Teil davon .. is ja so gesehen auch kopiert, zumindest von der Idee her, wenn mans denn doch per Hand abtippt Denke das sollte man nicht so wild sehen, kann mich dem genannten "letzten Satz" da auch nur anschliessen

 

[FatFire]

Ich hab noch nie ein System.exit() gebraucht wenn ich alles "richtig" gemacht habe:

Alle Ressourcen aufräume, Threadpools runterfahren, alle Netzwerkverbindungen kappen, ....

Aha, wie beendest Du denn dann grafische Oberflächen? Was glaubst Du denn, was passiert, wenn Du bei einem JFrame EXIT_ON_CLOSE setzt und das Fenster dann schließt? Riiiichtiiiisch:

 355:   protected void processWindowEvent(WindowEvent e)
 356:   {
 357:     super.processWindowEvent(e);
 358:     if (e.getID() == WindowEvent.WINDOW_CLOSING)
 359:       {
 360:         switch (closeAction)
 361:       {
 362:       case EXIT_ON_CLOSE:
 363:         System.exit(0);
 364:         break;
 365:       case DISPOSE_ON_CLOSE:
 366:         dispose();
 367:         break;
 368:       case HIDE_ON_CLOSE:
 369:         setVisible(false);
 370:         break;
 371:       case DO_NOTHING_ON_CLOSE:
 372:         break;
 373:       }
 374:       }
 375:   }

Man beachte Zeilennummer 9 bzw. 363.
Also kann man davon ausgehen, dass Du keine Programme mit grafischer Oberfläche schreibst? Natürlich sollte man vorher ein wenig aufräumen, aber das kann man auf Dinge beschränken, die die Integrität der Daten berühren (z.B. bearbeitet ein Thread im Hintergrund noch Daten, die dann auch auf die Platte geschrieben werden sollen). Der EDT beendet sich ja nicht selbst, nur weil die Main-Methode terminiert.

Gruß FatFire

 

[max40]

Man sollte auch WindowConstants.DISPOSE_ON_CLOSE verwenden!

 

[tuxedo]

@FatFire

Was "intern" in den Bibliotheken passiert juckt mich nicht die Bohne. Meine Aussage war lediglich: Wenn man alles richtig macht muss man nicht selbst explizit System.exit() aufrufen.

- Alex

 

[FatFire]

Man sollte auch WindowConstants.DISPOSE_ON_CLOSE verwenden!

Ja, und dann hat man doch wieder irgendwas vergessen (einen herumlungernden Thread z.B.) und dann läuft das Ding einfach weiter...ja ich weiß, an sowas sollte man sowieso immer denken.

Was "intern" in den Bibliotheken passiert juckt mich nicht die Bohne.

Ich finde sowas eigentlich ziemlich interessant. Immerhin ist das die Grundlage für unsere Programme.

Gruß FatFire

 

[bygones]

Ich finde sowas eigentlich ziemlich interessant. Immerhin ist das die Grundlage für unsere Programme.

interessant ja, aber just for fun ... mich interessiert eher obs das tut was es vorgibt ;-)
wie es das macht und was es da macht ist mir auch so ziemlich schnuppe...

 

[FatFire]

interessant ja, aber just for fun

Also ich schaue mir die API gerne mal an, wenn ich selber mit irgendeinem Konstrukt, dass ich selber programmiert habe und zu dem es vielleicht eine ähnliche Entsprechung bereits gibt, an, wenn ich mit meiner Version eventuell Probleme habe oder mit der Performance unzufrieden bin. Da bin ich schon oft auf Hinweise gestoßen, wie man es besser machen kann (okay, die API ist vielleicht auch nicht immer das Optimum, aber es steckt halt doch einiges mehr an Erfahrung drin).

Gruß FatFire

 

[Illuvatar]

Bin grundsätzlich derselben Meinung wie tuxedo... und EXIT_ON_CLOSE zu setzen ist für mich ien Fall von explizit System.exit aufrufen. Auch mit dispose sollte das Programm korrekt terminieren.

 

[FatFire]

Hm, okay, auch wenn ich nicht so ganz den angeblich sehr faden Beigeschmack von System.exit verstehe (also wenn man die wichtigen Dinge die evtl. im Hintergrund ablaufen im Griff hat, dürfte das ja sowieso kein Problem sein), werde ich mich da jetzt einfach mal der erfahreneren Mehrheit beugen. Grundsätzlich ist beides kompliziert, sobald ich mehrere Threads nutze. Im einen Fall könnte ich was abwürgen, was noch nicht fertig ist (die Ressourcen gehen dank des VM-Shutdowns ja auch nicht flöten und werden wieder freigegeben), im anderen Fall besteht halt die Gefahr das irgendwelche Sachen weiterlaufen und die VM am Leben halten, die eigentlich überflüssig sind. Aber das Einsehen kommt, wenn man sich überlegt, dass diese weiterlaufenden VMs halt eher beim Aufspüren von Fehlern dienlich sind und damit eher erkannt werden, als "abgewürgte" Programme und Fehler die daraus entstehen.
Deswegen mal ++ an Alex, max40 und Illuvatar.

Gruß FatFire

 

[Steev]

Ich bin der Meinung, dass man alle Möglichen Problemfälle eliminieren sollte. Und dazu gehört nunmal auch, dass irgendlwelche Threads im Hintergrund weiterlaufen.
Wie man das tut, das bleibt jedem selbst überlassen. Ich persönlich nutze, wie schon gesagt, nachdem ich sicher gestellt habe, dass alle wichtigen Berechnungen usw. beendet wurden, zusätzlich System.exit.
Der Standard tuts auch und ich denke das es genauso richtig ist, als wenn man das System.exit vermeidet und die Selbstterminierung nutzt.

Gruß
Steev

 

[tuxedo]

Naja. Wenn man System.exit() nur nutzt um auf "Nummer sicher" zu gehen wäre das für mich auch okay. Aber zu sagen: "So, hier ist das Ende des Programms, um's "aufräumen" kümmert sich schon das Terminieren der JVM" ist halt IMHO der falsche Ansatz (nicht dass ich das hier irgendwem unterstellen möchte/wollte. Wollte es nur erwähnt haben).

- Alex

 

[Steev]

Aber zu sagen: "So, hier ist das Ende des Programms, um's "aufräumen" kümmert sich schon das Terminieren der JVM" ist halt IMHO der falsche Ansatz

Das wollte ich auch nie so gemeint haben. Man sollte natürlich dafür sorgen, dass alle "wichtigen" Threads/Pools auslaufen. Manchmal, vor allem bei komplexeren Programmen oder wenn man Packages nutzt, von denen man nicht genau weis, wie sie intern aufgebaut sind, läuft dann noch irgendein Thread im Hintergrund weiter. Dafür würde ich dann System.exit nutzen, da man ja sonst X java-Tasks hat, die vieleicht noch Dateien blockieren usw.

 

[tuxedo]

Das wollte ich auch nie so gemeint haben.

...

(nicht dass ich das hier irgendwem unterstellen möchte/wollte. Wollte es nur erwähnt haben)

 

[faetzminator]

Ich bin eigentlich auch strikt gegen System.exit(), aber manchmal kommt man nicht drum herum. Da gebe ich Steev völlig recht. Z.B. hatte ich vor einiger Zeit mit irgendwelchen hängengebliebenen Threads von der Pirc Bot Lib, trotz disconnects.

 

[Spacerat]

Ist "System.exit()" nicht eigentlich ein Ansatz um verschiedene, in einer Doku definierte Exitcodes (Fehlercodes) statt Exceptions an einen Aufrufer (z.B. ein Batch-Process) zurückzugeben? Z.B. so:

class JavaApp
{
  public static void main(String[] args)
  {
    try {
      JavaApp.execute(args);
      System.exit(0); // Alles OK;
    } catch(Throwable e) {
      e.printStacktrace();
      System.exit(-1); // Fataler Fehler
    }
  }

  //...
}

 

[Steev]

Soweit ich weis ja. In C++ ist es auf jedem Fall auch so, dass Fehler über die Rückgabe der main erkannt, bzw. zurückgegeben werden.

 

[Spacerat]

Ja, neee, is Klar... Die Frage war rein rhetorisch gestellt. Wollte damit nur sagen, dass "System.exit()" durchaus Sinn macht. Wie wollen denn jene, die dessen Verwendung strikt ablehnen, ihre Exitcodes an die Batch zurückgeben? Etwa mittels Parsen der geworfenen Exception? Standardmässig wird halt 0 oder -1 zurückgegeben.

 

[tuxedo]

Also ich persönlich hab bei eigenen Programmen noch keine Exit-Codes benötigt. Aber klar, wenn man mit Exit-Codes arbeiten will macht System.exit() natürlich Sinn

- Alex

 

[FatFire]

Zumindest für Programme, die leicht über Kommandozeile zu steuern sind, ist das natürlich besser, weil man da nie sicher sein kann, dass die nicht vielleicht doch einfach mal im Rahmen eines Scripts genutzt werden.

Andererseits hab ich da schon soviel Moppelkotze gesehen...hier mal ein Beispiel:

}catch(Exception Exception1){
	System.exit(0);
}

Über die Qualität dieses Programms lasse ich mich mal nicht weiter aus, der Quellcode ist eh die Hölle (man beachte nur den groß geschriebenen Variablennamen). Und dann der Sinn: wenn ein Fehler auftritt, beende das Programm und signalisiere, dass alles in Ordnung war...

Generell macht wohl alles Sinn, was Java so an Features, Optionen und Möglichkeiten zur Verfügung stellt. Aber dann muss man auch wissen, wie man es benutzen muss.

Gruß FatFire