Secure Hash Algorithm oder etwas ähnliches

Dravere schrieb:

Dann hat man das Problem in der übergeordneten Methode und so weiter bis zur main . Dies ist definitiv keine Lösung sondern ein hässlicher Workaround.

Dieses "Problem" soll dich davor schützen potentielle Fehlerquellen zu ignorieren. Oder möchtest du lieber, dass sich dein Programm mit einem häßlichen Stackdump verabschiedet?

Dravere schrieb:

Ich schreibe mir lieber kurz eine eigene getSHA256Instance Methode, welche keine Exception wirft.

Und was machst du, sollte MessageDigest.getInstance() scheitern?

Dravere schrieb:

Also wenn ich nach der Java SE Dokumentation gehe, dann werde ich auf Appendix A verwiesen:

Java SE API Dokumentation / Appendix A schrieb:

The JDK Security API requires and uses a set of standard names for algorithms, certificate and keystore types. The specification names previously found here in Appendix A and in the other security specifications (JSSE/CertPath/etc.) have been combined in the Standard Names document. ...

"Standard Names document" ist eine Weiterleitung auf ein Dokument mit den möglichen Namen, worin man die folgenden findet: MD2, MD5, SHA-1, SHA-256, SHA-384 und SHA-512. Wenn man dies so liest, klingt das eher danach, dass diese Algorithmen auf allen Java SE Implementationen vorhanden sein müssen.

Nein, nur die Namen sind festgelegt.

Dravere

Dasd schrieb:

..., aber in diesem Fall berechtigt, da es sich ja möglicherweise um eine Nutzereingabe handelt.

Wie bitte? Du weisst schon, dass man dies für ALLES hinschreiben kann? Es könnte alles eine Benutzereingabe sein! Was ist das bitteschön für ein Argument?
Zudem habe ich bisher noch sehr selten gesehen, dass jemand !frei! den Hash Algorithmus auswählen konnte, in dem er ihn als String eingab. Das Höchste der Gefühle war bisher aus einer Liste vordefinierter Werte. Und sogar dies war erst einmal.

Normalerweise gehört ein bestimmter Hash Algorithmus zu einem bestimmten Ablauf. Da kannst du nicht beliebig zwischen Algorithmus A und B hin- und herwechseln. Wenn daher Algorithmus X nicht vorhanden ist, dann kannst du gleich einpacken.

Dasd schrieb:

In dem Fall ist auch das weiterwerfen als RuntimeException schlecht, da diese ja ggfs. bis nach ganz oben durchfliegt und dein gesamtes Programm abschießt.

Gut, dann fällt es bei den Tests gleich auf, dass der Algorithmus nicht vorhanden ist. Um genau zu sein sogar bereits bei den Unittests.

Z schrieb:

Dieses "Problem" soll dich davor schützen potentielle Fehlerquellen zu ignorieren. Oder möchtest du lieber, dass sich dein Programm mit einem häßlichen Stackdump verabschiedet?

Ich weiss schon, wieso Checked Exceptions eingeführt wurden. Ich kenne das ganze Marketing Blabla. Tatsache ist, dass es meistens nicht funktioniert. Die Leute sind so genervt von diesen Checked Exceptions, dass sie die Exception eben Leer fangen. Z.B. so:

try { Thread.sleep(100); }
catch(InterruptedException ex) { }

Ja, das bringt dann wirklich viel, falls die Exception doch mal auftritt
Von daher habe ich viel lieber einen Stackdump. Dann weiss ich, dass ich etwas falsch gemacht habe. Oder vielleicht war es auch gewollt.

Schlussendlich kann man auch in der main die Exceptions abfangen und noch einen kontrollierten Shutdown durchführen.

Z schrieb:

Und was machst du, sollte MessageDigest.getInstance() scheitern?

Ich freue mich über einen kontrollierten Absturz. Denn dann habe ich ein riesen Problem. Dieser Algorithmus muss vorhanden sein. Falls dies wirklich mal irgendwo auftauchen würde, würde ich dann wohl meine eigene Implementation anbieten, falls er auf dem System nicht vorhanden ist. Oder suche mir eine Third-Party Implementation. Allerdings ist er auf allen Systemen, welche zum Einsatz kommen, vorhanden.

Der Algorithmus muss vorhanden sein, daran führt kein Weg vorbei. Und diese Überprüfung findet bereits in den Unittests statt, welche automatisch vom CI-Server durchgeführt werden.

Grüssli

Dasd

Dravere schrieb:

Dasd schrieb:

..., aber in diesem Fall berechtigt, da es sich ja möglicherweise um eine Nutzereingabe handelt.

Wie bitte? Du weisst schon, dass man dies für ALLES hinschreiben kann? ...

Gebe zu, war ein etwas schwaches Argument. Es sei denn, man betrachtet auch die JVM selbst als "Nutzereingabe".

Dravere schrieb:

Dasd schrieb:

In dem Fall ist auch das weiterwerfen als RuntimeException schlecht, da diese ja ggfs. bis nach ganz oben durchfliegt und dein gesamtes Programm abschießt.

Gut, dann fällt es bei den Tests gleich auf, dass der Algorithmus nicht vorhanden ist. Um genau zu sein sogar bereits bei den Unittests.

Oder auch erst beim Kunden, wenn der doch eine andere JVM verwendet als die Unittests. Und ich kann Java-Programme, die man nur mit Java runterladen kann, nicht leiden.

Und ob das Prinzip der checked exceptions funktioniert obliegt doch der Entscheidung des Programmierers, oder?