public class GlibException
extends Exception
It is inappropriate for a public API wrapper method to throw this Exception. It is to be caught and re-thrown as a new Exception of an appropriate Java type. For example, if a function uses this mechanism to report being unable to locate a file on disk, then the wrapper method should do the following:
public String getModificationDate(String filename) { try { NativeLibrary.getModificationDate(this, filename); } catch (GlibException ge) { throw new FileNotFoundException(ge.getMessage()); } }
We map native functions that take a GError**
argument to
throwing this Exception if the function actually returns an error via that
parameter; the error parameter is masked from the binding hacker's view by
being handled in the C side JNI code.
Note that GError
s are meant as Exceptions in the Java sense
of the term; they do not represent crashes nor RuntimeExceptions; they are
conditions that the programmer will need to create appropriate user
interface code for to allow the user to deal with.