Re: [Lush-devel] open-read/open-write

[Ralf J. <jue...@cs...>]

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
>>>> Lus...@li...
>>>> 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
>> Lus...@li...
>> 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
> Lus...@li...
> https://lists.sourceforge.net/lists/listinfo/lush-devel
>