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