but I
>just wanted to chime in regarding your use of cfreturn from your
examples.
>In my mind (and I'm sure there may be those who disagree), it's not a
good
>practice to return true/false values from method calls in the manner in
>which you have done so. Returning true/false now couples the CFC to
your
>application code because I'm assuming your calling code is doing
something
>like:
I've heard this argument before but could never really grasp the basis
of it: it seems to me that ANY return, by necessity, couples your code.
You have input (of specific, defined types) and output (of specific,
defined types).
>If it's anything like that, then your CFC is now "stuck" having to
always
>use true/false (or 0/1 or whatever) as a return value. What if your
>requirements change which forces you to decide, using your delete
example,
>that you need to return the remaining structure instead of true/false?
Now
>all your application code breaks.
But by your same argument my requirements would NEVER change the results
as the instant I choose to return ANYTHING I've then coupled my code.
;^)
Again - sense the argument is applicable to any return set you can never
rally say "if requirements change" as any return value would need to be
handled by the calling code. The argument always circles round to
either set return values or never set return values.
>My suggestion would be to have a returntype of void and then use
>cftry/cfcatch around the method call and trap for known possible
exceptions
>there. That's a "cleaner" separation of your application code and your
CFC.
>
>Of course, as I mentioned, there are those who disagree (this
discussion
>came up recently on the CFC list), but I've always had better
flexibility
>when I've used void.
That seems even more "stuck" to me - then you're implementation code has
to know (and trap and respond to) possible exceptions for the method.
So if your requirements change (it seems) you'll have to change your
method (perhaps, to throw a new exception) and your calling code (to
trap the new exception). You may also have to examine all the places
the method is called to ensure that they handle this new exception well.
In my case I may have to change the component and the caller as well:
but I could add a new method (thus maintaining backwards compatibility
with all my old code since I haven't changed the method) or add a new
optional argument ("returntype" perhaps) - again maintaining complete
backwards compatibility.
CF doesn't have overloaded methods, but you can (sorta) mock them in
many circumstances).
I may be missing something big (I've been known to) but this seems much
cleaner to me than having the caller aware of error types.
Jim Davis
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
