&warningto let users know this. A bad thing is that, there is no way to know how the condition is raised. Think about this piece of code.
(import (scheme base) (scheme write)) (define-syntax safe-execute (syntax-rules () ((_ expr ...) (with-exception-handler (lambda (e) #t) (lambda () expr ...))))) (guard (e (else (display e) (newline) (raise e))) (safe-execute (raise "error huh?")))The
safe-executejust wraps given expression with
with-exception-handlerso that it can propagate non continuable condition to caller but can continue the process if the condition is just an warning. Now the problem is that, it doesn't propagate the raised condition as it is but modifies to something
&non-continuable. For example, if you write the same code in R6RS and run it on Chez Scheme then the original condition's information disappears. (not sure if this is a bug of Chez though.)
So to keep my mind calm and mental health as healthy as possible, it is better to detect if the given condition is raised by
raise-continuable. However there is no way to do it with portable way. If you are an R6RS user, you may have slight hope, which is checking
&non-continuable. If a script just wants to tell you an warning, then it usually raises an
&warningcondition. Thus checking this would make you a bit happy. Although,
raisecan take any Scheme object including
&warningso this solution depends on the behaviour or philosophy of libraries. Moreover,
elseneeds to re-raise the caught condition with
raise-continuable. This may cause something unexpected result if such a
guardexpression is wrapped by
Now, look at R7RS. It becomes totally hopeless. It doesn't have condition type, so the only hope that R6RS has is gone. The behaviour of all of related procedures and macro are the same as R6RS and it doesn't provide a procedures which can check if the condition is continuable or not, either. So this is totally depends on implementations.
If this is the case, then how the implementations behave. I've tested above piece of code with 4 implementations, Sagittarius, Chibi, Gauche and Foment. The results are followings;
- Sagittarius - compounded the condition with
- Chibi - changed condition with "exception handler returned" message (I guess)
- Gauche - didn't print message at all (bug?)
- Foment - propagated original condition.
errorit did print an error object. So it may not allow user to raise non condition object.
I'm not yet sure how important handling runtime exception is on Scheme. I've never written code that considers error other than just catching and logging. So this may be a trivial case.