Nachdem ich mich jetzt einige Tage lang mit Kotlin beschäftigt habe, bin ich noch etwas zwiegespalten, ob Kotlin mit seinen Ansätzen, es wirklich besser oder einfach nur anders macht.
Einiges was da an Java kritisiert werde, halte ich in Java sogar für besser gelöst, wobei ich aber durch aus die Kritik verstehe. Zum Beispiel haben== und equals() schon genug Leute/Einsteiger verwirrt.
Kotlin macht es anders. == und === sind wirklich logisch und nachvollziehbar. Es folgt der Umsetzung in PHP oder JavaScript. == vergleicht den Wert und === vergleicht die Referenz.
Aber ist == als Ersatz für equals() wirklich besser?
Date d = new Date();
MyDateImpl md = new MyDateImpl();
Es ist durchaus möglich das eine Klasse von mir sich mit sich mit einer standard
Java-Klasse vergleichen lässt, aber die standard Java-Klasse nicht mit meiner, da deren Existenz der standard Java-Klasse natürlich vollkommen unbekannt ist.
val d = Date()
val md = MyDate()
if(d == md){
println("== 1")
}
if(md == d){
println("== 1")
}
Ist das jetzt beides das selbe? Konnte ich auf die Schnelle nicht heraus finden.. werde ich wohl mal testen müssen.
Ist es falsch das Java einen zwingt eine Exception zu fangen, wenn explizit eine geworfen werden kann.
Also das Fehler dort behandelt werden, wo sie auftreten und man sie nicht immer bis ganz nach oben reichen sollte?
public class ThrowExample {
private void method1() throws Exception {
throw new Exception("test");
}
public void call() throws Exception {
this.method3();
}
}
Bei Java kann es so nie passieren, dass am Ende eine Exception auftaucht, von der man nie wusste, dass sie geworfen wurde. Weil sie entweder schon mit einem Try-Catch-Block gefangen wurde oder aber man über die Existenz dieses Exception mit Hilfe des "throws" an der Methode direkt informiert wird.
PHP hat mit Exception ab PHP 7.0 viel verbessert, aber um die Wahrheit zu sagen, ist das was ich noch gerne hätte ein "throws" damit ich weiß, dass in der Methode, die ich gerade verwende, das Werfen einer Exception implementiert wurde.
Fehler Behandlung ist schwer und Exceptions als brauchbare Fehlermeldungen an den Benutzer hoch zu reichen ist nicht einfach... aber einfach dann die Exceptions bis zum Benutzer durch laufen zu lassen ist doch eher der falsche Weg und ein gutes Exception-Handling Framework wäre die bessere Lösung gewesen.
Deswegen sehen ist den Verzicht auf den Zwang Exceptions fangen zu müssen in Kotlin eher negativ und nicht als Vorteil.Nur als einen Punkt nun dem Entwickler aufgehalst wird (er muss sich nun darum kümmern, dass Exceptions richtig behandelt werden), wo vorher der Compiler einen dabei unterstützt hat auch alle Exceptions richtig zu behandeln.
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?