<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" xmlns:xi="http://www.w3.org/2003/XInclude" type="topic" id="gerror" xml:lang="de">

  <info>

    <link type="guide" xref="index#specific-how-tos"/>

    <credit type="author copyright">

      <name>Philip Withnall</name>

      <email its:translate="no">philip.withnall@collabora.co.uk</email>

      <years>2015</years>

    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>Umgang mit und Melden von Laufzeitfehlern</desc>

    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">

      <mal:name>Mario Blättermann</mal:name>

      <mal:email>mario.blaettermann@gmail.com</mal:email>

      <mal:years>2016</mal:years>

    </mal:credit>

    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">

      <mal:name>Christian Kirbach</mal:name>

      <mal:email>christian.kirbach@gmail.com</mal:email>

      <mal:years>2016</mal:years>

    </mal:credit>

  </info>

  <title>GError</title>

  <section id="gerror-usage">

    <title>Verwendung von GError</title>

      <link href="https://developer.gnome.org/glib/stable/glib-Error-Reporting.html">GError</link>

      is the standard error reporting mechanism for GLib-using code, and can be

      thought of as a C implementation of an

      <link href="http://en.wikipedia.org/wiki/Exception_handling">exception</link>.

      Any kind of runtime failure (anything which is not a

      <link xref="preconditions">programmer error</link>) must be handled by

      including a GError** parameter in the function, and setting a

      useful and relevant GError describing the failure, before returning from

      the function. Programmer errors must not be handled using GError: use

      assertions, pre-conditions or post-conditions instead.

      GError should be used in preference to a simple return code, as it can

      convey more information, and is also supported by all GLib tools. For

      example, <link xref="introspection">introspecting an API</link> will

      automatically detect all GError parameters so that they can be converted

      to exceptions in other languages.

      Printing warnings to the console must not be done in library code: use a

      GError, and the calling code can propagate it further upwards, decide to

      handle it, or decide to print it to the console. Ideally, the only code

      which prints to the console will be top-level application code, and not

      library code.

      Any function call which can take a GError**, should

      take such a parameter, and the returned GError should be handled

      appropriately. There are very few situations where ignoring a potential

      error by passing NULL to a GError** parameter is

      acceptable.

      The GLib API documentation contains a

      <link href="https://developer.gnome.org/glib/stable/glib-Error-Reporting.html#glib-Error-Reporting.description">full

      tutorial for using GError</link>.

  </section>

</page>