> You expose implementation details to the outside with those recover points.
Of course not, no more than an exception or an error code "exposes implementation details". Condition restarts are part of a library's API, since they're a way for library users to interact with the library (in this case, to customize the handling of some error conditions)
> For this specific example, the better behavior (imho) would be that parseEntry always returns. So it returns ParseError instead of throwing it.
How and why is it a better behavior, especially if — unlike this contrived example — there are 5 frames of foreign code between the caller and the condition being signalled? Return or exception will have to unwind those frames, the point of a condition is that you don't, instead right there the library can provide a hook through which the library user can respond to the question: "how do I handle [this error]?"
Of course not, no more than an exception or an error code "exposes implementation details". Condition restarts are part of a library's API, since they're a way for library users to interact with the library (in this case, to customize the handling of some error conditions)
> For this specific example, the better behavior (imho) would be that parseEntry always returns. So it returns ParseError instead of throwing it.
How and why is it a better behavior, especially if — unlike this contrived example — there are 5 frames of foreign code between the caller and the condition being signalled? Return or exception will have to unwind those frames, the point of a condition is that you don't, instead right there the library can provide a hook through which the library user can respond to the question: "how do I handle [this error]?"