With the following piece of code, I am able to cause a runtime Critical Error crash once the execution reaches the
catch as OutputVar clause following
else:
Code: Select all
try
MsgBox 'try'
catch
MsgBox 'catch'
else
MsgBox 'else'
catch as ErrorException
MsgBox 'catch as ErrorException'
Code: Select all
Critical Error: Invalid memory read/write.
Line#
001: Try
002: MsgBox('try')
003: Catch
004: MsgBox('catch')
005: Else
006: MsgBox('else')
---> 007: Catch as ErrorException
008: MsgBox('catch as ErrorException')
009: Exit
The program is now unstable and will exit.
The error seems to occur only when
catch-as clauses appearing last are involved. Rearranging the clauses prevents the Critical Error from occurring, however, it also gives rise to other rather peculiar issues:
Code: Select all
try
MsgBox 'try'
catch as ErrorException
MsgBox 'catch as ErrorException'
else
MsgBox 'else'
catch KeyError ; ErrorClass may be left unspecified as well.
{
MsgBox 'catch KeyError'
throw ; Re-throw to have the default error dialog display the details of the caught exception.
}
Here, the
try-statement's body is executed, then follows the
else's since no exceptions were thrown. What is surprising is that the last
catch clause is also executed, despite having intentionally opted to restrict it as much as possible by specifically choosing one of
KeyError,
PropertyError or
MethodError. What exception is being thrown that causes the
catch clause to be stepped into? Perhaps, none at all. My attempt to re-throw the exception (so as to promote it to an unhandled one) fails to produce an error dialog. Could it be that the
catch line is ignored altogether and execution simply falls down through to the
MsgBox? Why then does
throw not result in a default unhandled exception being emitted?
The current spec dictates:
- catch may follow try or other catch clauses
- one else per try may follow other catch clauses
- one finally per try may follow try, else or other catch clauses
According to it, the scripts above ought to have been deemed syntactically incorrect at compile time.
As a side note, I think a
try-else (that is to say, not requiring a
catch clause) construct should be permitted.