exceptions

[Alexander Schmolck]

hungjunglu at yahoo.com (Hung Jung Lu) writes:

> There are a few lessons learnt from younger programming languages,
> like Io. 

I'm a bit suprised we have to learn from IO given that at least on superficial
inspection, IO mostly seems to self as ruby is to smalltalk.

> One lesson is that you really would like to avoid rigid statement syntax.

How do younger languages like IO make this point more forcefully than lisp,
smalltalk etc -- languages which have been around for decades?

I also suspect that the statement/expression distinction is beneficial at
least for inexperienced programmers (a declared target audience of python),
simply because it means that there are less ways to express the same thing and
nesting is limited -- in other words, I believe there is some trade off
involved.

> In the example of the original topic of this thread, you cannot
> intercept/override exception handling mechanism because the
> try:...except:... block is not a function.

I don't think having try/except functions instead of statements provides a
sufficient solution. Apart from the fact that functions in themselves don't
provide an adequate control flow mechanism for exceptions, I don't want to
have to write my own error handling mechanisms in order to be able to deal
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.

> Similar situations happen with issues regarding aspect-oriented programming.
> In a language like Io, everything is a method that send message to an
> object. Even If(...) statements are methods, as well as loops. The advantage
> is you can intercept things at your heart's content. 

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

> In comparison, Python's exception handling is not interceptible, because
> exception handling is hard-coded in syntax.

I don't think syntax is the sticking point here -- you could do some
additional, possibly useful, things if raise where, say, a method, but I can't
see how it would go anywhere near solving the problem.

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

> You can then intercept at that level: either by actually throwing an
> exception, or by redirecting it to some user intervention funtion, or by
> totally ignoring it (like using a 'pass' statement.)

Yes, but this is clearly insufficient.

> 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 --
Common lisp and Dylan, for example, support continuable conditions and can
hardly be called protype-based.

> As for Python's interactive programming, I've done some experiment
> before. It's not totally impossible. It's a bit uncomfortable. Python
> does have module reload and weakref. When you use these tools
> properly, you can achieve a high degree of non-stop programming.

I know -- I currently don't depend on weakref, but I use reload quite a lot
and I do all my programming in interactive sessions which sometimes last days.

> It does not come as part of the language per-se. You need to build up some
> tools yourself first.

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

'as