Lucifers,
For the Python bindings, all Clownfish objects inherit from Python's `object`,
which allows them to be used in a Python context without conversion or
wrappers. It would be nice if Clownish::Err inherited from Python's
Exception, for similar reasons.
We don't need to use Python's existing exception classes from Clownfish -- and
it's not realistic to attempt a lowest-common-denominator exception class
hierarchy which reconciles the extensive facilities of Python, Ruby, Java, C#,
etc. Instead, it would suffice to be able to use the Python host's error
handling facilities with Clownfish exceptions -- raise them, catch them, etc.
# Catch all Clownfish errors.
try:
...
except clownfish.Err as e:
...
# Catch all Lucy errors.
try:
lucy.IndexSearcher.open(index='/path/to/index')
except lucy.Error as e:
...
# Catch only locking errors from Lucy.
try:
lucy.Indexer.open(index='/path/to/index')
except lucy.LockError as e:
...
This basic approach, which should work for all hosts and be safe to embrace as
"idiomatic Clownfish", is described in the Python tutorial on user-defined
exceptions:
https://docs.python.org/3/tutorial/errors.html#tut-userexceptions
When creating a module that can raise several distinct errors, a common
practice is to create a base class for exceptions defined by that module,
and subclass that to create specific exception classes for different error
conditions...
Unfortunately, we run into a multiple inheritance problem in Python: Python's
`Exception` class has member variables, causing a clash at the offset where
the Clownfish `klass` member variable resides.
Perhaps we can solve this problem by making Clownfish's exceptions under
Python wrap an host object which implements an interface, similar what to Nick
proposed back in December:
http://s.apache.org/h0K
Marvin Humphrey
