>1) What happens if the proposed default does not conform to the specified >type? I.e., you specify a type of "Numeric" and specify a default of >"hello". While this may not be likely when hard-coding a default value, >there are plenty of time where the default is determined by some other >variable's value. Then an error is thrown and the blocked code takes effect.
>2) Adding a closing CFPARAM tag to include error-processing code does not >seem to include an elegant way of differentiating between different reasons >for the error. Was the error caused because of an invalid type, because it CFTRY gives a number of error types. The same can exist for CFPARAM. >3) What if I don't want or expect the default value to be used in case of a >type-mismatch? This could break existing code. If there's no closing CFPARAM tag, then the tag throws an error as it does normally. The only difference between what happens now and what I'm proposing is that my proposal captures the error and allows a block of code to deal with it rather than throwing it up and hoping there's something to catch it. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:232307 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
