public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
From: Andreas Rottmann <a.rottmann@gmx.at>
To: guile-gtk@sources.redhat.com
Subject: Re: GError
Date: Mon, 02 Jun 2003 09:20:00 -0000	[thread overview]
Message-ID: <8765novns8.fsf@alice.rotty.yi.org> (raw)
In-Reply-To: <20030526172355.GA6014@lark> (Andy Wingo's message of "Mon, 26 May 2003 18:23:55 +0100")

Andy Wingo <wingo@pobox.com> writes:

> Hi Kevin,
>
> On Mon, 26 May 2003, Kevin Ryde wrote:
>
>> Andy Wingo <wingo@pobox.com> writes:
>> >
>> > With regards to GError, I think the solution you propose is too much
>> > like C programming.
>> 
>> Oh, well, if it's nice and close then at least people familiar with
>> the C style will find the guile interface comfortingly similar.  Or
>> vice versa even.
>
> I'm not sure that an identical function mapping is really a goal. I am
> programming in scheme because I prefer it to C. In making these
> bindings, the goal has been to make the functionality of the gnome APIs
> available from scheme, not strict API transliteration. I don't think
> throwing exceptions will bother anyone who chooses scheme over C.
>
> A quick search through gnome/defs shows the following occurences of GError:
>
>  * Gdk: 7 uses, all regarding file i/o (pixbuf loading and saving,
>    mostly)
>  * Pango: 1 use, pango_parse_markup
>  * GConf: a boatload of uses, for a boatload of reasons: permissions,
>    client-server communication, etc etc
>  * applets: 1 use, setting something gconf-related
>  * libgnome: 4 uses, regarding failure to display help or uris
>  * glib: only appears in g_error_*
     ^^^^^^^
Not really true; there are quite a bunch of uses in glib:

~% grep GError /usr/include/glib-2.0/glib/*.h | wc -l
     68

> These are the sorts of things exceptions are made for. Furthermore,
> exposing GError to the programmer leads to nastiness on the scheme side
> of things.
>
> You could implement exceptions by adding 'c-only to the typespec and
> extending g-wrap to ignore, from the scheme side, parameters with
> 'c-only in their typespecs. The scm->c and c->scm ccodegens would still
> be run, however, allowing the error to be initialized and checked.
>
I agree that throwing exceptions instead of using GError is probably
the way to go; especially if you take this into account (from the GLib
manual):

,----
| GLib provides a standard method of reporting errors from a called
| function to the calling code. (This is the same problem solved by
| exceptions in other languages.)
`----

Regards, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

It's GNU/Linux dammit!

  reply	other threads:[~2003-06-02  9:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-24 11:49 GError Andy Wingo
2003-05-25 23:16 ` GError Kevin Ryde
2003-06-02  6:51   ` GError Andy Wingo
2003-06-02  9:20     ` Andreas Rottmann [this message]
2003-06-06 22:59     ` GError Kevin Ryde
2003-07-22 14:22       ` GError Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8765novns8.fsf@alice.rotty.yi.org \
    --to=a.rottmann@gmx.at \
    --cc=guile-gtk@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).