exceptions

[Hung Jung Lu]

Alexander Schmolck <a.schmolck at gmx.net> wrote:
> How do younger languages like IO make this point more forcefully than lisp,
> smalltalk etc -- languages which have been around for decades?

Sorry, the last time I used Lisp was more than 20 years ago. I might
have to look it up again. I tend to rely on people that have more
experience. Io was based on experience from lots of other languages.

> with some limited subset of errors raised in *my* code -- I want to be able to
> deal with *all* errors in an interactive session, no matter where they were
> raised and I don't want to have to rewrite (or slow down) *any* code in order
> to do so.

One typical example mentioned in AOP is precisely exception handling.
If you look at Python's internal way of handling exception (read the
manual part on extending and embedding,) errors are typically
indicated by returning a NULL value. And there are a few functions to
call to set exceptions. That is, internally, Python exceptions are
implemented going through function mechanisms, any how. Now, if these
functions could be interceptible a la AOP, there you go with "catching
*all* errors."

Sure, I understand you don't want to write any code. You just want to
be the end user and enjoy the free ride. But someone has to write it,
at some level. What you are saying is that you don't want to be this
someone. All the nice interactive, edit-and-continue features in the
various languages are not born out of magic, they were written by
someone, right? :)

> It would allow some interception, but I don't think enough for my heart's
> content because exceptions are completely different beasts from functions,
> certainly in python (dynamically scoped ones, for starters).

Exceptions in Python are implemented as (a) returning typically a NULL
value in Python functions at the C level, (b) setting exception
informations in global static variables, often via usage of some
functions like PyErr_SetString(). And in this regard, conceptually is
not different from AOP way of exception handling. And in this regard,
perfectly interceptible via function overrides, if it were not C but
some other language a la Io.

What I am saying is, it is totally possible to design a language where
exceptions are implemented using AOP approach, where each function
could return an additional implicit value (or a NULL value as in the
case of Python.) Now, the function (or "metafunction") in your AOP
code that handles the exception raising or catching can be overridden,
if you are using something like Io where all functions can be
overriden. That is, exception handling conceptually can be done via
functions. And in Microsoft C++, this is in fact the way how
exceptions are implemented: by including an extra return value. It's
just too bad that the end user cannot override internal C/assembler
functions. (There are products to do this type of overriding.
Profilers, memory leak detectors, debuggers, etc. are good examples...
in their "instrumentation" phase, they do AOP-ish insertion of
additional code and override the normal behavior.)

In short, for many language implementations, exceptions ultimately are
based on function features. They are not "completely different
beasts". Mostly everything ultimately comes down to plain-vanilla
function calls.

> > It does not mean all hope is lost in Python. But it does mean that
> > instead of using the raise... statement in Python, you need to call a
> > function/method instead. 
> 
> Such an approach doesn't really help much -- not only because I obviously
> can't (and don't want to) rewrite all the code that might raise an exception
> (which often isn't even python).

I know, that's why I said "it does not mean all hope is lost". It
doesn't help much, but it helps a little.

> Yes, but this is clearly insufficient.

Do you have any better idea? Short of stopping whining and starting to
re-write the Python interpreter yourself? I am sure you are totally
welcome to do so. :)

> > Interactive programming with features like edit-and-continue still has
> > room to grow (most edit-and-continue features are not transactional,
> > that is, you cannot revert changes easily.) But in my opinion that's
> > an arena for prototype-based languages, 
> 
> I don't see how prototype-based languages have a particular edge here --

It does. You just don't see it. Most people can't see it. And I am not
telling the details. :) Smart people know what I am talking about. And
I'll just leave it at that. Sorry, can't say anymore. :)

> I know -- I currently don't depend on weakref, 

Weakref is the key, at least that was my experience. I urge you to
think again on why weakrefs are necessary. Whether to use metaclass,
AOP-ish approach, or brute force class changes, it's all just icing on
the cake. Weakref was the key, in my experience.

> This is one of the sticky points -- it requires some work and expertise (and
> even then you are a long way off from e.g. smalltalk) and this in turn is
> likely to mean that most python users won't get to experience the benefits of
> interactive development (which in turn presumably means that libraries and
> utilities often don't cater well for interactive use).

I know. Python has been criticized from many directions. But you
either live with the workarounds, or stop whining and do the work
inside the interpreter so others can enjoy your work. :) In my
personal case, I choose the first alternative. The advantage is that I
can keep whining. I am almost sure that this would also be your
choice. :)

regards,

Hung Jung