Readline read_history and write_history addition
Judah Jacobson
judah.jacobson at gmail.com
Mon Feb 4 16:49:18 EST 2008
On Mon, Feb 4, 2008 at 6:06 AM, Yitzchak Gale <gale at sefer.org> wrote:
> Simon Marlow wrote:
> > However, I do agree that exceptions should generally be used for
> > exceptional conditions, rather than for general control-flow. This is an
> > example of a *good* reason to avoid an exception: because to use an
> > exception for a non-exceptional condition is poor style.
>
> That is also my opinion. Some people have disagreed.
> So this should be the focus of the decision then.
I also agree that exceptions should only be used for exceptional
conditions; but I do think that this is one of those situations. I'll
try to explain why below. (Thanks, Yitzchak, for forking off the
thread about fixing limitations of MonadIO.)
I assume that the following conditions are already considered
exceptional (I haven't ever heard anyone complain that they throw an
exception):
- readFile : read a nonexistent file
- writeFile : write to a file in a nonexistent directory
- getEnv: retrieve an unset environmental variable
- System.Console.Readline.readInitFile: read a nonexistent .inputrc file
I think of readHistory and writeHistory as analogues to the above
functions. So calling writeHistory when the directory doesn't exist
should produce an exception. And if you call readHistory, either
check first that the file exists, or else expect that an exception
will sometimes be thrown (just as is already the case for readFile).
Packages like shellac-readline can wrap the two steps of "only
readHistory if file exists" in a higher-level abstraction; but
System.Console.Readline itself should just be a thin binding to the
readline APIs.
All that being said, this is a relatively minor issue, so if many
people are strongly opposed to throwing an exception even after what
I've said above, I'll accept the consensus decision. Barring that,
however, I'm in favor of the interface already used by other, similar
functions in the libraries.
Thanks,
-Judah
More information about the Libraries
mailing list