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 try-catch when there is no other option. But when there are, e.g. testing the type of a variable before casting it or using a fault handler, try-catch should not be used. That could make the code a bit convoluted though, so in cases where errors can occur at many points (e.g. processing data files from an external server) a try-catch may be preferable, not only for code style, but also because you are unlikely to be able to pre-empt and mitigate all the errors that might occur. 2009/3/5 Weyert de Boer <w...@innerfuse.biz>: > 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 >> 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-catch is only useful in rare >> situations; like file IO in an Air app. User input should be handled >> with restict and validators and http errors should be handled with a >> fault handler. What I'm saying is that well written/tested code >> rarely needs the overhead and verboseness of a try-catch block. In >> the event of un-caught errors, I personally want the Flash window to >> popup. While the dialog could be more elegant, the stack trace makes >> it easier to locate the problem and fix the bug quickly. Again, just >> my opinion. >> >> -TH >> >> --- In flexcoders@yahoogroups.com, "Kevin Benz" <kb...@...> wrote: >> > >> > 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". As functions/methods only >> > give you one return object, it is common practice to throw custom >> > errors/exceptions as they are a great mechanism for handling dynamic >> > environments. >> > >> > >> > >> > To answer your second question about a try-catch without statements in >> > the catch block. If this method is nested inside of another try-catch >> > block, then an exception here will be swallowed and not be caught in the >> > calling objects try-catch. >> > >> > >> > >> > KFB >> > >> > >> > >> > From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On >> > Behalf Of SJF >> > Sent: Tuesday, March 03, 2009 6:54 PM >> > To: flexcoders >> > Subject: [flexcoders] try, catch, finally ... >> > >> > >> > >> > Technically, it's good practice/professional to use try-catch-finally >> > blocks in your actionscript logic. This ensures a robust, easily >> > debugg-able application. >> > >> > However, can anyone comment if they actually use try-catch-finally or >> > whether anyone is for or against it's use. >> > >> > I ask because I've received an application (which streams vidoe) that >> > was blowing out numerous users CPUs to 100%. Upon further investigation, >> > it appears that a netstream event is firing 20 times a second, and >> > within the listener (listener function that is) for the event, there is >> > a try-catch-finally block. I removed the try-catch-finally and CPU usage >> > halved on my machine. >> > >> > Anyone care to comment for or against try-catch-finally and it's use. >> > >> > >> > >> > Steve. >> > >> > >> > >> > >> > -- >> > This message has been scanned for viruses and >> > dangerous content by MailScanner <http://www.mailscanner.info/> , and is >> > >> > believed to be clean. >> > >> >> > > > > ------------------------------------ > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Alternative FAQ location: > https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links > > > >
