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