On 2013-03-15, at 9:51 AM, Mikael mikael.rcv@gmail.com wrote:
A port-specific flag makes perfect sense, it matches the intention of providing specific, direct, fundamental error handling behavior exactly!
So this is as easy as it gets to do fwrite() < 0 checks :)
When zooming out and comparing, this makes perfect sense while a parameter object does not, in that it's not as specific (e.g. web server switching |##io-error-behavior| parameter to a value suiting its configuration, would mean that user code that it invokes in turn, would inherit the server's setting for its port use - not good at all).
Re the with-exception-handler possibility, presuming that it actually does work - and indeed it can be made to work by just hammering until it perfectly does - it is a workable solution. Considering though that IO error handling are really local and simple phenomena within the IO DSL/API and designed to happen All the time, involvement of the completely indirect code path of using the exception system and reliance on an execution-scope-global exception filtering procedure that does come with an element of execution overhead global to the entire execution scope, seems much less direct and fundamental than justified.
The port flag can be named |io-error| and have a procedure |io-error| as default value. The procedure takes one argument being an error object, and the procedure's return value is passed as return value of the Gambit IO procedure that failed. This way any IO user can both specify IO primitive return value and get a copy of the actual underlying IO error for later reference (debug etc), this is all that's needed.
What do you say?
The problem I see with the approach you propose (whether it uses a parameter or a port specific flag) is that the semantics of an "io-error" is vague. What is an IO error? The definition is important because exceptions that are IO errors are going to be processed using this new mechanism, and non-IO exceptions will use a different mechanism (normal exception handling).
The approach I propose does not have this problem because the programmer has complete control over the definition of an IO error. The exception object can be inspected to see if it qualifies as an IO error and an appropriate action can be taken. The definition of IO error can depend on the type of port, the type of primitive which caused the exception (read-u8, read-char, read), etc.
Marc