[jni] loadLibrary Exception abfangen

[darkeye2]

Hallo,

normalerweise kann man ja Exceptions abfangen, und entsprechend etwas unternehmen, nun nutze ich in einem Programm die System.loadLibrary funktion, um native bibliotheken zu laden, und immer wenn eine Datei nicht vorhanden ist, wird das prog einfach beenedet, und ich sehe den fehler nur in der konsole. Ich hab es schon mit try-catch versucht, klappt leider nicht.

Mein Ziel ist es den fehler abzufangen, und entsprechend in einem fester, das die anwendung öffnet, als status zu zeigen, dass die datei nicht gefunden wurde.

 

[irgendjemand]

der grund ist das das ein Error ist ...
und laut java-grundlagen soll man nur Exceptions catchen ... Errors nie !

 

[darkeye2]

achso, danke, das löst natürlich das problem, ... Error und nicht Exception abfangen.

Und in diesem fall macht es sehr wohl sinn, Errors zu catchen, weil das programm ja weiterhin genutzt werden kann, und man aus dem prog heraus die libs neu downloaden kann, aber wenn alles abstürzt, nur weil die bibliothek nicht am richtigen ort ist, ist es nicht sonderlich toll für den anwender

 

[irgendjemand]

ist dann aber ein zeichen für schlechtes design ...

desshalb find ich meincraft auch nicht so sonderlich super das dem user OutOfMemoryError an den kopf wirfst ...
weil das sind infos die den user eigentlich nicht zu interessieren haben

besser wäre es wenn du vor dem laden der prüfst ob diese überhaupt vorhanden ist und dann ohne exceptions einfach in einem [c]if(file.exists());[/c] zu prüfen ...

 

[tfa]

Selbstverständlich werden Errors bzw. alle Throwables letzten Endes aufgefangen und dem Benutzer eine vernünftige Fehlermeldung präsentiert. Alles andere wäre Blödsinn.

 

[darkeye2]

hmm, wieso ist es besser, wenn ich das vorher so prüfe, über das abfangen der Error hab ich entweder die lib geladen oder eben festgestellt, dass sie nicht vorhanden ist, und der user kriegt keine fehlermeldung, die er nicht versteht, sondern eine normale Nachricht, dass eine native datei nicht gefunden werden konnte, und die frage, ob er diese nun aus dem internet nachladen möchte.

 

[irgendjemand]

Selbstverständlich werden Errors bzw. alle Throwables letzten Endes aufgefangen und dem Benutzer eine vernünftige Fehlermeldung präsentiert. Alles andere wäre Blödsinn.

ja ... weil am ende die VM alles auffängt *wenn man z.b. alles mit [c]throws Throwable[/c] weiter werfen würde

@TO
du kannst auch über das normale prüfen dem user eine ordentliche fehlermeldung anzeigen ... mit dem unterschied das erst garkein Throwable ausgelöst wird was deutlich besseres design ist

 

[Guest2]

Moin,

die Bibliothek kann vorhanden sein und trotzdem kann das Laden fehlschlagen.

Den Error abzufangen und vernünftig zu behandeln macht hier imho durchaus Sinn.

Viele Grüße,
Fancy

 

[Marco13]

Seh' ich genauso. Man kann nicht so ohne weiteres ein [c]file.exists()[/c] machen, weil man den Dateinamen erstmal nicht kennt - der hängt nämlich vom Betriebssystem ab. Selbst WENN man ihn sich selbst zusammenbaut (geht natürlich) kann man die Datei immernoch nicht aufspüren: Bei loadLibrary werden auch Verzeichnisse berücksichtigt, die im PATH liegen. Und selbst WENN man sich hundetere Codezeilen antun will, bei denen man höchst wackelig-frickelig und Betriebssystemspezifisch irgendwelche File-Objekte aus Properties und Umgebungsvariablen zusammenbaut und durchprobiert, steht man immernoch vor dem Problem, dass im Zweifelsfall ein UnsatisfiedLinkError geworfen wird, wenn die DLL-Version nicht passt (oder aus 1000 anderen Gründen...).

Ich hab' in den LibUtils genau deswegen auch die ansonsten so "böse" Zeile

catch (Throwable t)

Ja, sieht nach üblen Krämpfen aus. Sind auch üble Krämpfe. Aber wenn jemand eine bessere Lösung hat, würde ich die natürlich gerne einbauen 😀

 

[irgendjemand]

naja ... es gibt schon unterschiede zwischen System.load(filename) und System.loadLibrary(libname) ...
worauf ich anspiele ist eigentlich System.load(filename) bei dem meines erachtens nur drei mögliche ergebnisse gibt

erfolg
fehler weil file nicht gefunden
fehler wegen dll-inkompatibilität

und den einen fehler wegen FileNotFound kann man durch ein exists() prüfen ...
auch kann man durch system-props rausbekommen ob eine x86 oder eine x64 VM verwendet wird und entsprechend die libs bennen ... so entgeht man zumindest dem fehler eine x64 dll in eine x86 vm laden zu wollen *vise-versa*

was System.loadLibrary(libname) angeht : mag zwar etwas bequemer sein da man die suche nach dem file dem OS selbst überlässt ... kann aber schon mal schneller zu fehlern führen wenn sich die lib nicht im path/classpath befindet oder man vergisst den lib-path beim starten entsprechend anzupassen ...
ist daher meines erachtens die schlechtere wahl ... mann sollte bei selbst mitgelieferten dlls System.load(filename) bevorzugen da man dort dierekt den entsprechenden pfad angeben kann *was auch aus einem jar herraus mit [c](new File(".")).getAbsolutePath();[/c] möglich sein sollte ...