Subject: Re: [ecasound] ECI more or less ready for use
From: S. Massy (firstname.lastname@example.org)
Date: Mon Dec 11 2000 - 00:44:12 EET
On Mon, 11 Dec 2000, Kai Vehmanen wrote:
> Now as for error handling, it's another very difficult area of interface
> design. If we wanted to use error types (assigned to integers or
> something), we'd need to specify a huge number of different error types
> (and maintain these lists in all implementations). And do you really need
> this information? If an error has happenend, you can usually determinate
> the cause from the context. Verbose error messages are mainly there for
> helping to develop the ECI app, not necessarily for runtime error
> handling. So my idea is this:
> e.command("c-select 1,2,3")
> if len(e.last_error()) > 0:
> print "Error while selecting chains 1, 2 and 3!"
> print "Succesfully selected chains 1, 2 and 3."
> print "I'm paranoid so let's check what chains ecasound thinks is select:" , e.last_string_list()
> Should there be more error-handling related services or do
> you think is this enough?
Hmm, it seems to make sense just now, at least so long as the error to
occur comes as the direct result of an issued command. But suppose an
error that can't be expected, one that occurs while the processing is
going on. Huh... let's say you have a "device is full" error. I don't
know how ecasound handles this currently as I've never been confronted
to this very error, but how could this case be handled through the ECI?
> . http://www.eca.cx ... [ audio software for linux ] /\ .
> . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <email@example.com>.
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Mon Dec 11 2000 - 00:47:34 EET