I've always intrepreted that article as saying that putting the try catch blocks in the correct position is important, not that throwing exceptions is wrong.
Anyhoo, it's somewhat moot in CF. CF has no provisions for transaction management (other than database transaction management), (unlike .NET with the System.EnterpriseServices package), so even you did have a multistep process that needed to get rolled back because an exception was caught, it can be a rather large undertaking. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Spike > Sent: October 11, 2004 3:11 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] File I/O CFC > > > In general I agree that exceptions are better than return > codes, but you > need to be more careful about how you write your code when > you use them. > It's very easy to inadvertently write code that is buggy... > > 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] > ---------------------------------------------------------- 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]
