Extending Python: exception handling

John Skaller skaller at maxtal.com.au
Mon Aug 23 22:29:31 EDT 1999


At 19:50 21/08/99 -0500, you wrote:
>
>    John> I would like to know how YOU are using exception handling OTHER
>    John> than for error management.
>
>It makes a reasonable substitute for the lack of labelled break statements
>on certain occasions.
>
>    class BreakLabel: pass
>    try:
>	for i in ...:
>	    for j in ...:
>		exit_cond = do_some_work()
>		if exit_cond: raise BreakLabel
>    except BreakLabel:
>	pass

Two questions:

	1) would you always use a user defined exception?
	2) What if you had labelled breaks?

Reason: suppose I implement labelled statements in Viper,
and suppose I assume that system exceptions (Attribute
errors, etc) are program faults -- would all your code work?

The above code would work, because it uses a user defined
exception. But consider:

	try:
		y = x.sqrt()
		print "Got class instance sqrt"
	except AttributeError:
		y = sqrt(x)
		print "Got sqrt of float"

This code might 'fail' under Viper, since 'sqrt' is a method
of floats. Even worse, in some cases a _compile time error_
might be detected by type inference. To illustrate:

	try:
		y = sqrt(x)
	except:
		y = x.sqrt()

Here, the programmer is assuming that if the builtin sqrt
function defined for floats fails, the object might be a
class emulating numbers, and try to call a sqrt method.
But the Viper compiler might _know_ that x is a class instance
and that the builtin function 'sqrt' only applies to floats,
and report an error. 

	Even worse, it might _deduce_ that x must be a float,
and then get confused seeing x.sqrt(), which might require
that x is an instance (depending on whether sqrt is a method
of floats or not).

	The basic problem is that in the presence of
dynamic typing and exception handling, type inference
is hard, especially because handlers for exceptions can
be lexically isolated from the point the exception is raised:
with a _complete_ flow analysis, the type inference system
wouldn't work in all cases. [and maybe not even then]


-------------------------------------------------------
John Skaller    email: skaller at maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia






More information about the Python-list mailing list