48 |
i.e., if the callback raises an exception then the handler can catch |
i.e., if the callback raises an exception then the handler can catch |
49 |
it without crossing it the continuation barrier. But what happens if |
it without crossing it the continuation barrier. But what happens if |
50 |
the handler raises another exception? This doesn't seem like an |
the handler raises another exception? This doesn't seem like an |
51 |
important concern, since the hander is under control of the same C |
important concern, since the hander is under control of the code that |
52 |
code that is trying to protect itself. It should be sufficient to |
is trying to protect itself. It should be sufficient to warn in the |
53 |
warn in the documentation that such exceptions produce undefined |
documentation that such exceptions produce undefined behaviour and |
54 |
behaviour and allow them to cross the continuation barrier. |
allow them to cross the continuation barrier. |
55 |
|
|
56 |
How should the callback procedure be passed to the interface and |
How should the callback procedure be passed to the interface and |
57 |
invoked? Should it be like scm_internal_catch where it's passed as a |
invoked? Should it be like scm_internal_catch where it's passed as a |
58 |
C procedure (scm_t_catch_body) which is applied to user data (void *)? |
C procedure (scm_t_catch_body) which is applied to user data (void *)? |
59 |
For a procedure designed to be used from C, this is the most |
For a procedure designed to be used from C, this is the most |
60 |
convenient, since constructing closures in C is not very convenient. |
convenient, since constructing closures in C is difficult. It also |
61 |
It also gives symmetry with scm_internal_catch. |
gives symmetry with scm_internal_catch. |
62 |
|
|
63 |
Hence the first four arguments to the C interface should be the same as for |
On the other hand, the body procedure is expected to be a Scheme |
64 |
the old scm_internal_cwdr: |
closure in most cases. This suggests implementing two C procedures, |
65 |
|
the first taking four arguments: |
66 |
|
|
67 |
scm_t_catch_body body, void *body_data, |
scm_t_catch_body body, void *body_data, |
68 |
scm_t_catch_handler handler, void *handler_data |
scm_t_catch_handler handler, void *handler_data |
69 |
|
|
70 |
The return value from the interface should be the result of calling |
and the second taking three arguments: |
71 |
|
SCM body, scm_t_catch_handler handler, void *handler_data |
72 |
|
|
73 |
|
If there is also to be a Scheme interface, then it would be implemented |
74 |
|
with a third variant: |
75 |
|
SCM body, SCM handler |
76 |
|
|
77 |
|
The second and third variants would be implemented by calling the |
78 |
|
first, similar to the old scm_call_with_dynamic_root and its wrappers. |
79 |
|
|
80 |
|
The return value from all variants should be the result of calling |
81 |
the body, unless an exception occurred in which case it's the result |
the body, unless an exception occurred in which case it's the result |
82 |
of calling the handler. So the return type is SCM, as for |
of calling the handler. So the return type is SCM, as for |
83 |
scm_internal_catch. |
scm_internal_catch. |
84 |
|
|
85 |
Yet to be discussed: libguile usage and threads, error handling and |
Yet to be discussed: libguile usage and threads, error handling and |
86 |
reporting, convenience of use, Scheme-level interface. |
reporting, convenience of use, Scheme-level interface. |
|
|
|
|
Proposal |
|
|
======== |
|