Say you have the following:
function addUser(...) {
createUser();
addUserToGroup();
}if addUserToGroup() throws an error there's nothing in the addUser() function to catch it and remove the newly created user.
This gets worse when you start to add new code to an existing application. If you decide that a method should start being able to throw an exception you need to make sure you know everywhere in the code that calls that method and whether or not you need to deal with cleanup.
Raymond Chen explains this far better and in more detail than I ever could here:
http://weblogs.asp.net/oldnewthing/archive/2004/04/22.aspx
Like I said, I prefer using Exceptions, but they're not the magic bullet that some people seem to think they are when compared to return codes.
Spike
Barney Boisvert wrote:
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.
--
-------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk
Do you cfeclipse? http://cfeclipse.tigris.org
----------------------------------------------------------
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]
