#474 closed enhancement (fixed)
Additional library procedure condition->list
Reported by: | Christian Kellermann | Owned by: | felix winkelmann |
---|---|---|---|
Priority: | major | Milestone: | 4.9.0 |
Component: | core libraries | Version: | 4.6.x |
Keywords: | condition->list | Cc: | |
Estimated difficulty: |
Description
I would like to add introspection facilities for conditions to our chicken library core. Programs should be able to know which properties are available.
Rationale:
Programs currently have not a good method of inspecting conditions. Property names have to be known in advance, there is no introspection facility as there is no way of querying the properties that are available.
csi's describe function atm does peek inside the slots directly.
Sometimes I do have the need to convert exceptions programmatically to either some other exception or structure. The way this can be done up to now is to use ##sys#slot and peek into the internal record structure which is fragile.
After some initial thoughts there is:
Way 1:
With the exception->list procedure properties and their values are returned in one list, ordered by exceptions.
Example:
Example: (condition->list http-client-condition) => ((exn (arguments (#<URI-common:...>)) (message "Client error: 400 Bad Request") (location call-with-input-request)) (http) (client-error (body "\"invalid UTF-8 JSON\"}") (response #<response>)))
(output shortened for readability)
Way 2:
Why everything into one list? Well I guess it could be split up into two parts, a query api for introspection and then the usual get-condition-property-accessor dance as well. For composite conditions this could amount to lists like:
((exn location arguments message) (http) (client-error response body))
This could then again traversed to extract the wanted properties.
I have attached a patch that implements this procedure as described in way 1. As well the additional test case for it. As a bonus it adds test cases for the exception slots so we can tell it this breaks in the future.
I am interested in suggestions or even a better way to do this. Maybe way 3...
Attachments (2)
Change History (9)
Changed 14 years ago by
Attachment: | condition_list.patch added |
---|
comment:1 follow-up: 2 Changed 14 years ago by
Keywords: | condition->list added |
---|---|
Owner: | set to Christian Kellermann |
Status: | new → assigned |
This is nice. I have applied the patch in "experimental". Can you provide some documentation for the manual?
Changed 14 years ago by
Attachment: | exception_manual.patch added |
---|
patch against experimental d287f2ce0e153ba250e1111d9f484c0d52e22b75 adding condition->list to the manual exceptions section
comment:2 Changed 14 years ago by
Replying to felix:
This is nice. I have applied the patch in "experimental". Can you provide some documentation for the manual?
I have attached a patch for this. However I am unsure if this is the right place in the manual. I placed it there because it is an enhancement from srfi-12.
However I think that the whole page should be reordered. It should emphasise the procedures users should use and not its ancestry from srfi-12 IMHO.
comment:3 Changed 14 years ago by
Priority: | not urgent at all → major |
---|
comment:4 Changed 14 years ago by
Owner: | changed from Christian Kellermann to felix winkelmann |
---|
comment:5 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
patch against git experimental branch commit 35e6429e4f4397c654cec39e0d2bc5cf42073a8d