Hey thanks for the review :) On Fri 15 Nov 2019 10:03, Ludovic Courtès <l...@gnu.org> writes:
> 0. Do I get it right that ‘throw’ and ‘catch’ are not “deprecated” in > the sense of (ice-9 deprecated) and are instead simply not the > “preferred” exception mechanism? Correct. I think we could envision deprecating them in some future but not within the next couple years at least. > 1. I see things like: > > +(define (make-condition type . field+value) > + "Return a new condition of type TYPE with fields initialized as specified > +by FIELD+VALUE, a sequence of field names (symbols) and values." > + (unless (exception-type? type) > + (scm-error 'wrong-type-arg "make-condition" "Not a condition type: ~S" > + (list type) #f)) > > and: > > + (unless (symbol? key) > + (throw 'wrong-type-arg "throw" "Wrong type argument in position ~a: > ~a" > + (list 1 key) (list key))) > > 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.) Yes. So right now Guile is in a bit of a transitional state -- it still signals 99.9% of errors via `throw'. Probably we want to change to have structured exceptions for almost all of these. To preserve compatibility we would probably need to mix in an &exception-with-kind-and-args to all of these exceptions, or otherwise augment `exception-kind' and `exception-args' to synthesize these values when appropriate. > Guix has ‘&location’ error conditions, which I’ve found useful when > combined with other error conditions in cases where location info from > the stack isn’t useful: > > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/utils.scm#n832 > > I wonder if (ice-9 exceptions) should provide something like that. Neat :) Yes sure. I think, any exception type can be added to (ice-9 exceptions) -- there's little "name cost" like there is in boot-9. Which reminds me, I want to make boot-9 do a (resolve-module '(ice-9 exceptions)) so that the more capable make-exception-from-throw always gets installed. > 2. What are you thoughts regarding exposing structured exceptions to C? > I’ve always been frustrated by ‘system-error’ :-). Guix has a hack to > augment ‘system-error’ with information about the offending file name: > > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n520 > > If the POSIX bindings would emit a structured ‘&system-error’ record, > that’d be pretty cool. I don't know :) Right now raise-exception is marked SCM_INTERNAL. Probably it should be public. There is no public C API for any of this new functionality, as it stands; a TODO. Regarding exception objects, there are two questions: one, how to create exceptions of specific kinds; I suspect scm_make_system_error () would be fine, and probably you want scm_make_exception to be able to mix various exceptions. Second question, do we want to expose accessors too? It can be a lot of API surface and I am a bit wary of it. But, perhaps it is the right thing. I do not know. > 3. I wonder if we could take advantage of the new ‘&message’ exception > to start i18n of error messages. It might be as simple as telling > xgettext to recognize ‘make-exception-with-message’ as a keyword, though > currently there are few calls to ‘make-exception-with-message’ followed > by a literal. Eventually this will get called by `error', I think; Guile's R7RS layer in wip-r7rs defines `error' as being: (define (error message . irritants) (raise-exception (let ((exn (make-exception-with-message message))) (if (null? irritants) exn (make-exception exn (make-exception-with-irritants irritants)))))) But yes this is definitely something to think about it. > 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 :) > Bah, you give us a present and I reply with an additional wishlist. > ;-) :) I hope that the exceptions work can serve as a foundation for further incremental, compatible improvement. Cheers, Andy
