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

[Peter Bex]

On Wed, Aug 27, 2014 at 01:50:13AM +0400, Oleg Kolosov wrote:
> 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.

Thanks!

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

It sounds like you're looking for condition-case.  I think this takes
care of the handling of various different kinds of exceptions in a very
elegant way, and it's actually my favorite part of the whole condition
system in CHICKEN (though, strictly speaking, not part of SRFI-12):
http://wiki.call-cc.org/man/4/Exceptions#additional-api

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

That's exactly what condition-case leverages in order to offer its
convenience.

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

How can standarization make it worse?

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

Most definitely!  CHICKEN is promoted as a "*practical*, portable Scheme
system", and experiences in practice should drive our design and progress.
If something turns out to be unwieldy, it has to change.

> 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 disagree.  Any really *mature* library should raise fully decorated
and conditions that make different situations easily distinguishable, so
that whatever goes wrong, a program will always be able to either
recover from it, or provide detailed information to the user as to what
went wrong and why.

This should not get in the way when writing quick scripts, of course!
However, with condition-case I find it easy to only handle the type of
exceptions that I'm interested in and ignore others (which will cause
them to bubble up the environment of handlers, to the next one that
decides to handle it, or bomb out with an error message).

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

I really get the feeling you've missed out on the existence of
condition-case :)

Cheers,
Peter
-- 
http://www.more-magic.net