Try/catch is a good thing, but terribly slow, so I'm not surprised that taking
it out helped CPU utilization.
First thing to consider is whether any code in the try{} block will actually
throw errors. If so, what is the likelihood of it throwing errors, and how the
application should respond if there is an error.
It turns out that the release player does not show the uncaught error dialog
box, and since there is no code following the try {} block, a user of the
application on a release player will not notice any difference whether there is
a try {} block or not. But because you are probably using the debugger player,
as am I, if an error is thrown and not caught, we'll see the uncaught error
dialog and that will be a terrible user experience.
Note that try/catch performance is costly enough that I would encourage you to
have methods return results to indicate failure like null or-1 instead of
throwing errors.
Alex Harui
Flex SDK Developer
Adobe Systems Inc.<http://www.adobe.com/>
Blog: http://blogs.adobe.com/aharui
From: [email protected] [mailto:[email protected]] On Behalf
Of Jake Churchill
Sent: Tuesday, March 03, 2009 7:54 PM
To: [email protected]
Subject: Re: [flexcoders] Another on try-catch-finally ...
No, the try/catch block is a good thing. I'm not sure what updateListArray()
does but there is always a potential for an error. What if bPollingDatabase is
not yet created, then an error will be thrown. The empty catch simply means
that IF an error happens, nothing special is done to correct it.
SJF wrote:
I have a head-cold (hence the possibly obvious answer to this question) and a
block of code as such:
function checkResponder(e:Event = null):void
{
try
{
bPollingDatabase = true;
updateListArray();
}
catch (err:Error)
{
//
}
}
Now considering there is no code in the 'catch' block, there can be absolutely
no benefit whatsoever to using try-catch-finally in the above instance.
Is this correct?
