In my experience try/catch blocks have been most useful in dealing with sdk
component life-cycle errors.
It is useful to throw custom errors for debugging purposes but rarely do i need
to handle them in a production environment and run another process.
Bjorn
--- In flexcoders@yahoogroups.com
I guess the other thing to consider is where you are using them. If
you put them in code that's called frequently it's probably more of a
problem than if you are using them in code that's called occasionally.
On 05/03/2009, at 10:42 AM, Sam Lai wrote:
I thought Alex said before that except
I thought Alex said before that exceptions don't appear for users
running the standard Flash Player (i.e. not the debug one). Hence the
user won't even know something went wrong; rather the app will
probably just enter some unknown/unusable state and effectively
freeze.
There are cases for using t
I respectfully disagree with not handling exceptions and let them raised
in the player. Of course, eating exceptions is terribly bad. Yes,
raising exceptions because user input is bad is a long stretch.
> Hi Kevin,
>
> Try-Catch blocks are an absolute necessity as without them, you are
> puttin
I need to agree with Tim on this one. I posted my thoughts on try... catch
in a blog post a little while ago.
http://blog.natebeck.net/2009/01/tip-of-the-day-when-to-use-try-catch-finally/
On Wed, Mar 4, 2009 at 2:33 PM, Tim Hoff wrote:
> Hi Kevin,
>
> Try-Catch blocks are an absolute necess
Hi Kevin,
Try-Catch blocks are an absolute necessity as without them, you are
putting the operation of your software into the hands of user input
errors, http errors, unintended consequences as well as the myriad of
things that exist outside the "Happy Path".
I respectfully disagree. IMHO, try-
6 matches
Mail list logo
