As it should. If you can't get the separator, it can't do anything. You're always better of dying from an unrecoverable error sooner rather than later. This way the calling code can either just die as well, or catch the error and try something else.
With error codes, the calling code is littered with conditionals, rather than having the error trapping code nicely segmented out into designated error processing blocks (CFCATCH). Exceptions are also enormously more flexible than simple return codes. There's nothing you can do with return codes that you can't do with exceptions. However, there are a lot of thing you can do with exceptions that you can't do with return codes. For example, consider a method that needs to return a query. If it fails, it needs to return 1 for credendials denied, 2 for SQL error, 3 for connection error, etc. How do you declare the return type of the method? It can't be both numeric and query. And what about the calling code? It needs to call the method, then check if the result is numeric or a query, and then deal with each possible case. Now consider using exceptions. The method is declared to return query, and will throw CredentialsDeniedException, SQLException, or ConnectionException if something goes wrong. Now the calling code just calls the method, knows it's getting a query back, and keeps right on processing. If you want to try and recover from any of the exceptions, you can use a CFTRY..CFCATCH block, which nicely segregates out the behaviour in normal circumstances from the behaviour in exceptional circumstances. cheers, barneyb On Mon, 11 Oct 2004 14:25:08 -0600, Joseph Flanigan <[EMAIL PROTECTED]> wrote: > Interesting observation about finding return codes awkward. > > My suggesting about return codes is as a programming technique to handle > exceptions rather than cfthrow. > > 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. > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com I currently have 4 GMail invites for the taking ---------------------------------------------------------- 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]
