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