Readline read_history and write_history addition

Robert Dockins robdockins at fastmail.fm
Tue Jan 22 08:22:06 EST 2008


On Tuesday 22 January 2008 12:00:51 am Sterling Clover wrote:
> 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.

I agree.  For reference, the way I have handled this myself up to now is:


foreign import ccall "readline/history.h read_history" read_history :: 
CString -> IO Errno

doReadHistory :: FilePath -> IO ()
doReadHistory path = do
  err <- withCString path read_history
  if err == eOK
     then return ()
     else ioError $ errnoToIOError
              "System.Console.Shell.Backend.Readline.doReadHistory"
              err
              Nothing
              (Just path)


I think it's a pretty good solution.

> --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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries




More information about the Libraries mailing list