[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-ERROR (Version 1)
- To: CL-ERROR-HANDLING@SAIL.Stanford.EDU
- Subject: Issue: PATHNAME-ERROR (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 27 Sep 88 19:15 EDT
Any discussion/objections before this goes to X3J13?
Anyone think we should go with something more elaborate? That would
unfortunately make it less likely to pass unless there was pretty
strong across-the-board support -- but I'm not closed to the suggestion.
-kmp
-----
Issue: PATHNAME-ERROR
References: Condition System (Revision 18)
Category: ADDITION
Edit history: 25-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
There is no condition type for errors in pathname construction.
Proposal (PATHNAME-ERROR:NEW-TYPE):
Introduce a new condition type PATHNAME-ERROR for use with pathname-related
errors (such as might be generated by MAKE-PATHNAME and PARSE-NAMESTRING).
This condition is a subtype of ERROR.
Test Case:
(HANDLER-CASE (MAKE-PATHNAME :NAME "FOO" :TYPE 3.2)
(PATHNAME-ERROR () NIL))
=> NIL
Rationale:
Pathname errors are a common source of program porting problems.
The ability to recognize and handle them might improve the
robustness of some portable code.
Current Practice:
Several implementations probably already have this type or something
similar. In some cases, the name may be slightly different and a
synonym might need to be added.
Cost to Implementors:
Very small if any.
Cost to Users:
None. This is a compatible change.
Cost of Non-Adoption:
Lessened ability to deal selectively with pathname errors when
multiple kinds of errors might be possible.
Benefits:
Improved selectivity in error handling.
Aesthetics:
No significant impact.
Discussion:
A more elaborate theory involving specific types for invalid pathname
components and/or problems parsing namestrings might be useful. With
that level of specificity, it would be possible to specify slot names
for the error types. This proposal is intended as a non-controversial
step in the door to provide minimal essential functionality.
Pitman supports this proposal.