RE: [Flashcoders] Implicit setters and exceptions in AS2.0
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
Re: [Flashcoders] Implicit setters and exceptions in AS2.0
exceptions in async functions cause all sorts of conundrums at times. make certain you have a strategy for handling that use case On 9/28/06, David Bellerive [EMAIL PROTECTED] wrote: 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 -- j:pn http://www.lennel.org ___ 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
