Re: [Flashcoders] Implicit Setters: Is validation considered a good or bad OOP practice ?
3) Validate the value and it it's an undesired value, throw an error ? Here, the component prevents the user from assigning and undesired value like NaN or undefined and the user is alerted of the failure at runtime provided that he used a try catch statement. What do you guys think ? (3) definitly. It's called defensive programming. Try to have your API as much checked (type-wise and logical-wise) as possible. This will enforce your internal logic constraints and prevent faultly programs. For instance any other component of your application (an UI for example) will except your volume to be positive and not NaN so you cannot allow such values to be set. And you shouldn't ignore this error also since silently ignoring errors will make you and others lose hours of debugging when something goes wrong damn ! why this f... volume does not get set answer : because it's NaN Nicolas ___ 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: Is validation considered a good or bad OOP practice ?
so if it's a bad input, it cannot tell the object
that is modifying the setter property that something went wrong.
Not sure if it's the best practice, but if someone passes in a bad input to
your setter, in AS3 you can throw errors, such as:
public function set volume( val:Number ) {
if ( val == bad_news ) {
throw new Error( Volume Class - set volume(): Bad value passed in [ +
val+ ] );
}
}
Scott
On 9/25/06, Nicolas Cannasse [EMAIL PROTECTED] wrote:
3) Validate the value and it it's an undesired value,
throw an error ? Here, the component prevents the user
from assigning and undesired value like NaN or
undefined and the user is alerted of the failure at
runtime provided that he used a try catch statement.
What do you guys think ?
(3) definitly.
It's called defensive programming. Try to have your API as much
checked (type-wise and logical-wise) as possible. This will enforce your
internal logic constraints and prevent faultly programs.
For instance any other component of your application (an UI for example)
will except your volume to be positive and not NaN so you cannot allow
such values to be set.
And you shouldn't ignore this error also since silently ignoring errors
will make you and others lose hours of debugging when something goes wrong
damn ! why this f... volume does not get set
answer : because it's NaN
Nicolas
___
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
--
: : ) Scott
___
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: Is validation considered a good or bad OOP practice ?
Not sure if it's the best practice, but if someone passes in a bad input to
your setter, in AS3 you can throw errors, such as:
You can do the same thing in AS2, of course...
Jim Kremens
On 9/25/06, slangeberg [EMAIL PROTECTED] wrote:
so if it's a bad input, it cannot tell the object
that is modifying the setter property that something went wrong.
Not sure if it's the best practice, but if someone passes in a bad input
to
your setter, in AS3 you can throw errors, such as:
public function set volume( val:Number ) {
if ( val == bad_news ) {
throw new Error( Volume Class - set volume(): Bad value passed in [
+
val+ ] );
}
}
Scott
On 9/25/06, Nicolas Cannasse [EMAIL PROTECTED] wrote:
3) Validate the value and it it's an undesired value,
throw an error ? Here, the component prevents the user
from assigning and undesired value like NaN or
undefined and the user is alerted of the failure at
runtime provided that he used a try catch statement.
What do you guys think ?
(3) definitly.
It's called defensive programming. Try to have your API as much
checked (type-wise and logical-wise) as possible. This will enforce your
internal logic constraints and prevent faultly programs.
For instance any other component of your application (an UI for example)
will except your volume to be positive and not NaN so you cannot allow
such values to be set.
And you shouldn't ignore this error also since silently ignoring errors
will make you and others lose hours of debugging when something goes
wrong
damn ! why this f... volume does not get set
answer : because it's NaN
Nicolas
___
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
--
: : ) Scott
___
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
--
Jim Kremens
___
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
