Wiki

Ticket #300 (new enhancement)

Opened 5 years ago

Last modified 5 years ago

allow to chain a few exceptions with a single body

Reported by: kobi7 Owned by:
Priority: minor Milestone:
Component: Cobra Compiler Version: 0.8.0
Keywords: Cc:

Description

<kobi7> can I chain a few exceptions with a single body?
<kobi7> catch SysException? | XException | YException
<kobi7> body of catch statement, that fits all of them
<CobraCommander> nope they have to be separate catches
<kobi7> in that case, the body is duplicated
<CobraCommander> you could break it out to a separate method
<CobraCommander> also in the case of "catch x as SysException? | XException | YException" there is the question of what type to give to "x"
<kobi7> ofcourse. I saw that syntax in a java proposal, maybe it got to java7. thought it's a nice addition
<kobi7>  http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html
...
<CobraCommander> so i presume you can use methods on "ex" that the two types have in common, but they don't spell that out and they don't show an example
<CobraCommander> also since .net doesn't have this feature, we'd have to map it. presumably by generating each "catch" block on behalf of the programmer
<CobraCommander> I guess the type of "ex" could be the greatest common denominator of all the types
<CobraCommander> the Cobra compiler already has code to compute such a thing because it is used in other places, like inferring the inner type of a list literal
<CobraCommander> if you don't want me to lose track of this idea, fill out a ticket at the cobra web site. :-)

Change History

Changed 5 years ago by kobi7

note: the exception types have to comply with the usage (in the following block of code).
otherwise, it is a compiler error.

if the implementation is to create the same code and duplicate the catch statements, then this will come to light anyway.

Changed 5 years ago by Charles

The Cobra compiler would do the error checking before the code generation. Plus the code generation for the JVM back-end would be different anyway.

Anyway treating the type as the GCD of all the types should work just fine.

Note: See TracTickets for help on using tickets.