[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.
References: Condition System (Revision 18)
Edit history: 25-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
There is no condition type for errors in pathname construction.
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.
(HANDLER-CASE (MAKE-PATHNAME :NAME "FOO" :TYPE 3.2)
(PATHNAME-ERROR () NIL))
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.
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.
Improved selectivity in error handling.
No significant impact.
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.