Hi :)
On Sat 16 Nov 2019 16:26, Ludovic Courtès <l...@gnu.org> writes:
> Andy Wingo <wi...@pobox.com> skribis:
>
>> On Fri 15 Nov 2019 10:03, Ludovic Courtès <l...@gnu.org> writes:
>>
>>> I guess we could add a specific ‘&type-exception’ exception or similar,
>>> which would allow us to improve error reporting (that can come later, of
>>> course.)
>
> What I meant is that type errors are “special” enough to deserve their
> own type more specific than the catch-all ‘&assertion-failure’ (just
> like there’s already a separate ‘&undefined-variable’, for instance.)
Agreed!
> Speaking of which, it seems that ‘set-guile-exception-converter!’ is
> currently private, but I wonder if the goal was to make it public (it
> seems to be unused)?
It was private also in the exception conversion work that Mark did,
FWIW; it just moved over as-is.
Honestly I think that now that exceptions are "primary" we should
probably move in the opposite direction: instead of adding more
converters from key+args to exception objects, we should encourage
exception throwers to switch from "throw" to "raise-exception", and
allow library authors to define converters in the other way from
exception object to the equivalent arguments for "catch". So I think
exposing set-guile-exception-converter! might be the wrong thing at this
point. Dunno tho.
> For instance, C bindings that currently call ‘throw’ could provide
> additional “exception converters” for the benefit of Scheme users
> who’d rather use structured exceptions. (That would also give less of
> an incentive to provide a C API for all of this.)
This is a good point!
FWIW Regarding C and migration, I have the impression that probably 90%
of exception throwers in C use the helpers from error.h
(scm_wrong_num_args and so on), which we can change transparently. A
remaining 5% might use scm_error_scm, for which a registry might make
sense, and 5% use scm_throw directly. These are just guesses tho.
>>> 4. Is ‘&warning’ actually used? Is the goal to make it continuable?
>>> That sounds great.
>>
>> Any exception can be raised in a continuable way. Whether a raise is
>> continuable or not depends on the value of the #:continuable? keyword to
>> raise-exception. I think that's the intention of &warning but I don't
>> really have instincts about how it might be used. Guile defines it
>> because it's in R6RS, but how it will be used is an open question :)
>
> I suppose the intent is to effectively allow users to implement the UI
> stuff as a sort of co-routine to support separation of concerns: you
> just raise a ‘&warning’ that some other code displays in its preferred
> way (console message, popup window, whatever) and eventually calls your
> continuation.
>
> That’s something I’ve been wanting for some time, because right now
> we’re able to separate out the UI concern for exception display, but not
> for warnings.
>
> However, it seems that the handler passed to ‘with-exception-handler’
> does not receive the continuation, so is it the case that currently
> handlers cannot resume exceptions? (Again not a showstopper IMO but
> rather another wishlist item :-)).
The handler runs within the continuation of "raise-continuable":
(with-exception-handler
(lambda (exn) (+ exn 30))
(lambda () (+ 2 (raise-exception 10 #:continuable? #t))))
=> 42
However I'm not sure this facility is what you want. Like for example
there's lots of false-if-exception / catch #t out there; that's
equivalent to:
(define-syntax-rule (false-if-exception expr)
(let/ec k
(with-exception-handler
(lambda (exn) (k #f))
(lambda () expr))))
So the exception handler there would intervene and get a first crack at
the warning, messing up your intent. To me warnings are like logging,
and logging is notoriously difficult to standardize :) If it were me I
would make a mechanism for warnings that had a with-warning-handler and
I would make sure to raise all warnings via a separate raise-warning
procedure or something, independent of exceptions. But that's just me
:)
Andy
