Couldn't reproduce against SVN build :

cedric@laptop:~/dev/workspace/boo-svn/sandbox$ cat exception.boo
try:
raise System.Exception()
except System.ArgumentException:
pass
cedric@laptop:~/dev/workspace/boo-svn/sandbox$ booc exception.boo
Boo Compiler version 0.7.6.2437 (CLR v2.0.50727.42)
exception.boo(3,14): BCE0043: Unexpected token: ..
1 error(s).

However it compiles fine if we import System and then use "except ArgumentException" as shown above.

Should we ensure the "name" is not a type ? or maybe we could allow the "name" to be a type reference here (as long as it is subclassing Exception? [1]) and just handles this transparently as in c# ?

[1] : as far as I know the CLR does not actually have this restriction but well...

We should definitely ensure "name" does not match the name of a valid type, or rather, if it is, to handle it as such. So these should still be valid:

except ex as ArgumentException:
  ...

except ex:    // (assume "ex as System.Exception")
  ...

And this should probably be valid as well:

except ArgumentException:  // (assume "__unnamed as ArgumentException")
  ...

Yup we envision the same on this

Let's wait the final word from Rodrigo on this though.

About the:

And this should probably be valid as well:

except ArgumentException:  // (assume "__unnamed as ArgumentException")
  ...

It should be valid, yes, but the semantics aren't changed. ArgumentException would be a variable name, in other words:

except ArgumentException:

is the same as:

except ArgumentException as System.Exception:

If you want to emit a warning for that I'm cool.

I think it's important for Boo to support unnamed exceptions in except blocks. Think of the usual:

try:
  i = int.Parse(s)
except FormatException:
  print "That ain't no integer!"

What I'm saying is that sometimes the type of exception is more important than the variable used to capture it. The existing semantics require users to use a dummy variable, which is IMHO contrary to the Boo spirit, being "structure for the sake of structure".

There are some resolution issues in here, though, because I could define a type 'ex' that derives from System.Exception and then try to do this:

try:
  value = 12/0
except ex:
  print "Caught"

In this case, should a variable ex be created, or should it use the type? Or, should we throw an error. I have a patch that I believe has a better, just as wrist-friendly, but clear syntax:

try:
  value = 12/0
except as DivideByZeroException:
  print "Zero can't support a fraction!"

I have created a sister issue regarding exceptions in general. The patch is attached to that issue. If someone decides to use

except ArgumentException:
  pass

then I believe that we could emit a warning that the name is the same as a valid type and suggest the alternate syntax.

except ArgumentException:

Should indeed issue a warning (or an error?) now that we accept "except as ArgumentException" for anonymous exception handlers.

warning

Fixed in rev. 3109