[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: PATHNAME-ERROR (Version 1)



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.