Exception API

[Ludovic Courtès]

Hi,

"Marco Maggi" <address@hidden> writes:

> "Ludovic Courts" wrote:
>>Indeed,  this exception  model is  not very  convenient.  In
>>some cases,  it's even hardly usable, as  examplified by the
>>`test-suite/lib.scm'   hacks  (use   of  regexps   to  parse
>>exception messages and determine their meaning...).
>
> But applications and test suites are different scenarios.

Well, test suites are one kind of application after all.  ;-)

The point is: sometimes, you need precise information about what went
wrong.  Even if you're not able to recover from the exception, you want,
at least, your application to notify its user in an intelligible way.
And you certainly don't want to parse an error message to get an idea of
what's going on (fortunately, error messages in Guile are not yet
translated!).

> "Ludovic Courts" wrote:
>>Ideally, Guile should  use some SRFI-3[56]-like mechanism to
>>represent exceptions.
>
> SRFI-35 defines  a complex value,  maybe too complex.  It is
> not  clear to me  if a  fine-grained hierarchy  of exception
> descriptors can really improve the quality of the code. 

I believe the principle behind this is that exceptions should not be a
second-class API.  Thus, an exception API should be designed to be
actually used.  ;-)

The current exception mechanism _is_ useful and it conveys important
information about the exceptions (documented under the ``Handling
Errors'' node) but the semantics are not crystal-clear compared to
"regular" APIs.  Consider for instance this:

  (lambda (key . args)
    (case key
      ((system-error)
       (let ((errno (car (cadddr args)))) ;; !!!
         (if (= errno ENOENT)
             ...)
         ...))))

and this:

  (guard (c ((i/o-no-such-file-error? c)
             (let ((file (i/o-error-filename c)))
               ...)))
     ...)

I think the latter looks clearer, especially to someone not familiar
with any of those mechanisms.  And it is also probably less
error-prone.  :-)

> Should  it  be possible  to  do  something without  breaking
> compatibility  by generalising  the 'key'  argument  and use
> upon it a generalised version of 'equal?'?

Yes, maybe allowing for arbitrary objects as the `key' argument would
help.

Thanks,
Ludovic.