> My suggesting about return codes is as a programming technique to handle
> exceptions rather than cfthrow.
Yes, I know . It's just that I feel more at home trowing exceptions to the
caller instead of using return codes. It's just a matter of taste I guess.
> I can see some immediate uses for your cfc, but it would have to be
> reworked to handle exceptions.
>
> Here is one case.
>
> variables.separator = getPathSeparator(); runs when the CFC is invoked. It
> calls createObject without any exception handling. If the createoject
> fails, the application crashes without any opportunity for in-line repair.
Back when I started instantiating Java APIs from CFML I used to wrap a
try/catch around every createObject("Java") call (I think you can see it on
a few older UDFs of mine on cflib.org and cfmentor.com). I've seen it to be
very much reliable, so I don't do it all the times anymore.
Unless you put try/catch everywhere, you have to make choices. In this
specific case I felt it wasn't worth to catch exceptions on this:
createObject("java","java.io.File").init("")
I had the feeling if the code above fails you have something very much
broken at the JRE level. But then again, I see your point. Choosing how many
potential exceptions to catch is quite a personal choice.
Massimo
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
