Boo

except clause variable names are not being checked by the compiler

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 0.9
  • Fix Version/s: 0.9
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

The compiler allows the following code to compile:

try:
raise System.Exception()
except System.ArgumentException:
pass

Issue Links

This issue relates to:
BOO-877 Exception Handling: Allow anonymous typed handlers Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Cedric Vivier added a comment -

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

Show
Cedric Vivier added a comment - 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...
Hide
Permalink
Avishay Lavie added a comment -

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")
  ...
Show
Avishay Lavie added a comment - 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")
  ...
Hide
Permalink
Cedric Vivier added a comment -

Yup we envision the same on this

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

Show
Cedric Vivier added a comment - Yup we envision the same on this Let's wait the final word from Rodrigo on this though.
Hide
Permalink
Rodrigo B. de Oliveira added a comment -

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.

Show
Rodrigo B. de Oliveira added a comment - 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.
Hide
Permalink
Avishay Lavie added a comment -

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

Show
Avishay Lavie added a comment - 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".
Hide
Permalink
Marcus Griep added a comment -

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.

Show
Marcus Griep added a comment - 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.
Hide
Permalink
Cedric Vivier added a comment - 
except ArgumentException:

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

Show
Cedric Vivier added a comment - 
except ArgumentException:
Should indeed issue a warning (or an error?) now that we accept "except as ArgumentException" for anonymous exception handlers.
Hide
Permalink
Rodrigo B. de Oliveira added a comment -

warning

Show
Rodrigo B. de Oliveira added a comment - warning
Hide
Permalink
Cedric Vivier added a comment -

Fixed in rev. 3109

Show
Cedric Vivier added a comment - Fixed in rev. 3109

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.