Re: open-read/open-write

Yann LeCun <[email protected]> Sun, 15 Nov 2009 17:46:34 -0500
Newsgroups gmane.lisp.lush.devel
Organization Courant Institute, NYU
Message-ID <[email protected]>
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
> 
> 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.
> >
> > 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).
> >>
> >> 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
> >>>
> >>> 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?
> >>>> 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
> >>>> _______________________________________________
> >>>> Lush-devel mailing list
> >>>> [email protected]
> >>>> https://lists.sourceforge.net/lists/listinfo/lush-devel
> >>
> >> ------------------------------------------------------------------------
> >>--- --- 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
> >> _______________________________________________
> >> Lush-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/lush-devel
> >
> > -------------------------------------------------------------------------
> >----- 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
> > _______________________________________________
> > Lush-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/lush-devel
> 
> ---------------------------------------------------------------------------
> --- 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
> _______________________________________________
> Lush-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lush-devel
> 


------------------------------------------------------------------------------
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