I think that's very well-put. ― Mike Keesey
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:flashcoders- > [EMAIL PROTECTED] On Behalf Of David Bellerive > Sent: Thursday, September 28, 2006 8:22 PM > To: flashcoders@chattyfig.figleaf.com > Subject: [Flashcoders] Implicit setters and exceptions in AS2.0 > > Last week, I sent a message to the FlashCoders list > asking if validating the values passed to setter > methods (in custom classes) was a good practice. > > After reading on how exceptions work in Java, here's > the solution I've decided to use in my setter methods > in AS2.0. > > If the client (the programmer using my custom class) > breaks his part of the contract by supplying my setter > method with an illegal value, I display an alert in > the output window using the trace statement and abort > the implicit setter method without assigning the > illegal value that was passed to the method. > > On the other hand, if the implicit setter method is > the one breaking the contract (it can't complete it's > task for whatever reason), I throw and exception. > > I've decided to use this method because AS2.0 doesn't > support checked and unchecked exceptions like Java. In > AS2.0, all exceptions are unchecked, meaning the > client isn't forced to catch any exceptions. But when > an exception goes uncaught, the function call stack > completely aborts. > > So, using this method, when the client is responsible > for breaking the contract (like passing an illegal > value to the setter method), he is alerted via the > output window in the Flash IDE. This way, he isn't > forced to respond to "low-risk" errors and the > function call stack won't abort under any > circumstance. However, the client cannot react to this > error at runtime. > > However, when the setter method is the one responsible > for breaking the contract, an exception is thrown and > the client has to catch it to prevent the function > call stack from aborting completely. If the client > doesn't catch the exception, the function call stack > is emptied and the program probably won't work as > expected. However, if the exception is caught (and it > should), the client has the possibilty to react to it > at runtime. > > In conclusion, when the error comes from the client > only alert the client. When the error comes from the > method, throw an exception. > > Any thoughts or comments on this ? > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
