Readline read_history and write_history addition

Sterling Clover s.clover at gmail.com
Tue Jan 22 00:00:51 EST 2008


It seems to me that the proper solution would be to throw the proper  
exception for the errno, warning of such an exception clearly in the  
documentation. If the user of the library wants to swallow the  
exception themselves and continue with a catch or bracket statement,  
they should have that option, but they should also have the  
flexibility to handle exceptions in a particular way, should they  
need that functionality. There's no reason a library binding should  
conceal any potentially useful functionality of the underlying  
library. If the errors that were returned were unique, Either String  
Bool might be an option, but as we've got a built-in standard for  
handling precisely the sorts of IO errors that are returned, it seems  
silly not to use it.

--S

On Jan 21, 2008, at 11:34 PM, Alexander Dunlap wrote:

> On Jan 21, 2008 10:27 AM, Judah Jacobson <judah.jacobson at gmail.com>  
> wrote:
>>
>> One more suggestion, from Robert Dockins (author of the Shellac and
>> Shellac-readline packages):
>>
>>> The only concern I have is that this patch doesn't seem to
>>> be handling errors properly.  read_history and write_history  
>>> should return
>>> errno, but this binding has them returning ().  These functions  
>>> do file
>>> operations and therefore can fail; we want (be able) to know when  
>>> that
>>> happens.
>>
>> I think we should just throw an error if those functions return a
>> nonzero value; for example, we already do that in the functions
>> readInitFile and parseAndBind.
>>
>> Thanks,
>> -Judah
>>
>
> I'm reluctant to use the throw an error solution because these
> functions failing does not have to be the end of the world (or even
> necessarily handled by the application). If the history file can't be
> found, the user just doesn't get their history restored (in fact, this
> may not even be a problem: if the user hasn't used the application
> before, readHistory will fail silently on the first run and then work
> fine after the history has been saved at the end of the first
> session). Similarly, writing or appending to the history file is
> generally not an essential task and can fail without terminating the
> program. (I know there's catch, but I don't think the programmer even
> has to worry about it that much.) I think that just returning a value
> for success and a value for failure would be appropriate.
>
> However, I'm not sure how we would implement it without using error.
> The usual Haskell solution would be to use Maybe, but what would we
> have Just of, since the functions don't return real values? Is Just ()
> an accepted idiom? (I've never seen it, but I haven't seen all the
> Haskell there is to see, either.)
>
> Thanks.
> Alex
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries



More information about the Libraries mailing list