Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Oleg Kolosov]

On 08/26/14 11:06, Peter Bex wrote:
> On Tue, Aug 26, 2014 at 10:29:23AM +0400, Oleg Kolosov wrote:
>> On 08/25/14 15:30, Peter Bex wrote:
>>> On Mon, Aug 25, 2014 at 10:31:44AM +0400, Oleg Kolosov wrote:
> Ah, I didn't understand that.  If we make it part of an egg it gets its
> own dedicated wiki page.  That could have as long an explanation as you
> want.

This could be even better. Looks like I've made a lot of noise for
nothing. Will study the implementation harder. Maybe I will be able to
write something there.

>> ... patterns, like CHICKEN do: (exn arity), (exn type), (exn syntax) etc.
>> Better yet - provide specialized match operator for decomposing
>> implementation specific error type and let the user spell out only
>> symbols, like:
>>
>> (match '(exn i/o net)
>>   ((or (! file) (! net)) (print "open error"))
>>
>> No need for predicates, accessors, composite constructors, etc. and
>> condition-case (guard) starting to look redundant.
> 
> Your matchable example assumes the code raising the condition is written
> by the same people who wrote the code which is handling it (or at least
> they read the docs).  If conditions belong to a particular type, generic
> code can catch them and at least inspect the components it knows about.
> You're right that the ability to raise arbitrary objects might cause
> trouble for code dealing with conditions, and that's a bit of a mistake.
> 

It is a good point. But this use case is the one that I'm trying to
improve here.

>> Condition properties (like location, arguments, etc.) look useful at
>> first sight, but I could not think of any use for them besides printing.
> 
> They're extremely useful when you go beyond the usual simple errors.
> For example, ... [ practical examples of composite conditions skipped ]

I agree, all of this clearly shows that the condition system could be
put to good use, looks like we have complex cases pretty much covered.

But what if I'm writing something like a shell scripts or quickly
prototyping? For example consider an embedded system where the script
can have some resources opened which can not be cleared by the OS (real
world non embedded example: loop mount file -> check some files -> copy
them -> unmount -- all of this should be a transaction with graceful
rollback). A crash is not an option, so I still need to handle all
errors carefully and want to distinguish between syntax (arity, type,
whatever), library (file not found, socket already in use, etc.) and my
own errors. Because the exception handler receives a single argument
which can be a condition, this pretty much forces me to use conditions
too. And given many things that can go wrong, this quickly goes out of
hand without special macros or helper procedures - handling code could
be larger than application logic.

The essential part is the "type" of the error that happened, ideally a
list of symbols. It is equally important for the caller and the handler.
The symbols are words that form vocabulary. It is easier to agree on
than data structures. There are a rich set of procedures for dealing
with lists. They are simple to understand, and the benefit of
composition is not lost: just cons and throw. There could be other
interesting usages like map/filter and re-throw, etc. Simple syntax.
This could be more than enough for many programs.

So the condition system is really flexible and powerful, especially for
larger programs, but bulky and restrictive for smaller. And the
standardization of properties will make the situation even worse, IMO.

Let the Java be an extreme example: it is almost impossible to write
robust code without an IDE assistance considering multitude of error
conditions, so it is quite common to declare everything as runtime error
(which is not checked by compiler) when prototyping and forget to go
back and handle everything properly once the initial implementation is
complete.

Given that we are using CHICKEN Scheme in production for almost 2 years
now, as the project grows, I am starting to see this kind of problems,
hence the argument that error handling should be as unobtrusive as
possible. This is anecdotal but still valid point IMO.

> The biggest problem with the SRFI-12 conditions is that the properties
> are a matter of convention: there is no guarantee that the "exn"
> condition really contains any of the usual properties (and in fact, most
> or all of them are optional). 

I view the providing of supplementary error information as a separate
issue. It can be extremely useful as in http client and postgres
examples but also very implementation specific as in debugger example.
It depends on the good discipline of the module implementor to provide
it, not everyone will bother, sometimes it does not make sense, but just
the possibility of having it makes the life harder IMO.

>> I think the implementation could find a way to provide this information
>> without burdening the user.
> 
> Don't hand-wave this away.  A replacement API should be well thought-out,
> and deal with all the use cases of the current system.

This is a complex problem, I have no experience in developing a full
blown programming language implementation, need more time to think about it.

Or maybe I'm missing something obvious and making an elephant out of a
fly, sorry for the wall of text then.

-- 
Regards, Oleg