headers
Ralf Juengling | 10 Nov 2009 06:23
Picon

open-read/open-write


The functions 'open-read' and 'open-write' do not
raise errors. The current behavior is this:

"The empty list is returned when an error occurs while
opening the file. .."

I can see that this may be useful. But I believe the
alternative behavior--open-read/write raising an error and
printing an informative error message when the operation
fails--is useful more often than the current behavior.

Does anybody remember why the current behavior was chosen?
Does anybody object if I change open-read/open-write (and
open-append) in lush2 to raise errors?

Ralf

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Permalink | Reply |
headers
Yann LeCun | 10 Nov 2009 14:01
Picon

Re: open-read/open-write

Yes, I object.

For an interactive srcipt language it's nice to have a function that
just throws an error, but for a "real" programming language, you need
one that just tells you the file doesn't exist so your program can
take corrective actions and not crash and burn (like fopen() in C).

The solution is to keep the current open-write/read/append as they are
(changing them would break too many things), but to add another set
higher-level function that throws errors (although that is kind of
what "(reading <file> ....)" does).

I don't have any good sugestions for name. Perhaps
file-open-r file-open-w file-open-a, or something.

  -- Yann

On Tuesday 10 November 2009, Ralf Juengling wrote:
> The functions 'open-read' and 'open-write' do not
> raise errors. The current behavior is this:
> 
> "The empty list is returned when an error occurs while
> opening the file. .."
> 
> I can see that this may be useful. But I believe the
> alternative behavior--open-read/write raising an error and
> printing an informative error message when the operation
> fails--is useful more often than the current behavior.
> 
> Does anybody remember why the current behavior was chosen?
(Continue reading)

Permalink | Reply |
headers
Ralf Juengling | 10 Nov 2009 16:20
Picon

Re: open-read/open-write


On Tue, 10 Nov 2009, Yann LeCun wrote:

> Yes, I object.
>
> For an interactive srcipt language it's nice to have a function that
> just throws an error, but for a "real" programming language, you need
> one that just tells you the file doesn't exist so your program can
> take corrective actions and not crash and burn (like fopen() in C).

Ok. What bugs me is that open-read also returns '()' when a
file does exist but it could not be opened for another reason
(network proplems, no permission, too many files open, ...),
and you have no clue what went wrong.

How about we let open-read return '()' when a file does not exist
but raise an error when an existing file cannot be opened?

Ralf

>
> The solution is to keep the current open-write/read/append as they are
> (changing them would break too many things), but to add another set
> higher-level function that throws errors (although that is kind of
> what "(reading <file> ....)" does).
>
> I don't have any good sugestions for name. Perhaps
> file-open-r file-open-w file-open-a, or something.
>
>  -- Yann
(Continue reading)

Permalink | Reply |
headers
Yann LeCun | 10 Nov 2009 16:36
Picon

Re: open-read/open-write

Again, I think we need to catch all errors that are not under the
control of the programmer, so that people can write applications that
don't just crash and burn.

libc sets an error code when something bad happens. Perhaps some
functionality of this sort could be implemented (perhaps based on the
fileinfo function), so that errors can be caught. As much as I dislike
the idea of "returning error codes by side effects", it's nice to
stick to models people are used to. 

Perhaps all of this could be handled with optinal arguments to
open-xxx. Without optional args, open-xxx would work as it does now,
with t as optional argument, it would do what you are suggesting
(throw an error whenever something goes bad), with a symbol as
optional arg it would set the symbol with the error code, if
necessary.

Just some random ideas,

  -- Yann

On Tuesday 10 November 2009, Ralf Juengling wrote:
> On Tue, 10 Nov 2009, Yann LeCun wrote:
> > Yes, I object.
> >
> > For an interactive srcipt language it's nice to have a function that
> > just throws an error, but for a "real" programming language, you need
> > one that just tells you the file doesn't exist so your program can
> > take corrective actions and not crash and burn (like fopen() in C).
>
(Continue reading)

Permalink | Reply |
headers
Ralf Juengling | 15 Nov 2009 23:04
Picon

Re: open-read/open-write


Hmm. Another approach would be to allow users to
define error-handler functions. But instead of making
that an optional argument, one would bind a dedicated
symbol, like 'system-error-handler' to a function. The
open-xxx implementations would check if a function is
bound to 'system-error-handler', and if so, would call
that function with an error code and stack-trace, say,
when an error occurs. If the symbol is not bound, then
the error would be silently ignored. An advantage of
this approach is that you could also catch errors that
originate in other functions that use open-xxx and that
don't care to catch errors themselves.

If that sounds like a good idea, then we need to hammer
out the details at some point. For the 2.0 release I
won't change open-read and friends, but for a future
release it would be good if we could come up with some
general, user-customizable scheme for handling errors in
lush.

Any other ideas?

Ralf

On Tue, 10 Nov 2009, Yann LeCun wrote:

> Again, I think we need to catch all errors that are not under the
> control of the programmer, so that people can write applications that
> don't just crash and burn.
(Continue reading)

Permalink | Reply |
headers
Yann LeCun | 15 Nov 2009 23:46
Picon

Re: open-read/open-write

There is a mechanism for catching errors by temporarily
redefining  the "debug-hook" function, but it's a little 
bit dangerous. This could be used, but very carefully.

  -- Yann

On Sunday 15 November 2009, Ralf Juengling wrote:
> Hmm. Another approach would be to allow users to
> define error-handler functions. But instead of making
> that an optional argument, one would bind a dedicated
> symbol, like 'system-error-handler' to a function. The
> open-xxx implementations would check if a function is
> bound to 'system-error-handler', and if so, would call
> that function with an error code and stack-trace, say,
> when an error occurs. If the symbol is not bound, then
> the error would be silently ignored. An advantage of
> this approach is that you could also catch errors that
> originate in other functions that use open-xxx and that
> don't care to catch errors themselves.
> 
> If that sounds like a good idea, then we need to hammer
> out the details at some point. For the 2.0 release I
> won't change open-read and friends, but for a future
> release it would be good if we could come up with some
> general, user-customizable scheme for handling errors in
> lush.
> 
> Any other ideas?
> 
> Ralf
(Continue reading)

Permalink | Reply |
headers
Ralf Juengling | 16 Nov 2009 00:14
Picon

Re: open-read/open-write


On Sun, 15 Nov 2009, Yann LeCun wrote:

> There is a mechanism for catching errors by temporarily
> redefining  the "debug-hook" function, but it's a little
> bit dangerous. This could be used, but very carefully.

I think this function is called from within 'error', that
is, after an error has already been raised, and it let's
you do a little bit of inspection.

The idea with an error-handler function would be a little
different. It would be called by a lush function like
'open-read' when it cannot succeed. It is then up to the
error-handler to decide whether to abort the program or to
do something else and to return to the caller to let
execution continue. 'Open-read' would return <nil> as it
does now, if the error-handler returns. A default
error-handler would simply call 'error' and abort the
program.

Ralf

>
>  -- Yann
>
> On Sunday 15 November 2009, Ralf Juengling wrote:
>> Hmm. Another approach would be to allow users to
>> define error-handler functions. But instead of making
>> that an optional argument, one would bind a dedicated
(Continue reading)

Permalink | Reply |

Gmane