If the exception included the bogus email address then it could be possible
to sort the original query by email address, and then you can assume that
any email address prior to the bogus one worked. Then you just have to
requery starting after the bogus address.
Yeah, I guess I would call throwing an exception when working on a group of
emails a defect... it seems like there should be better ways to communicate
the problem addresses back to the caller without aborting the entire job.
Mark
-----Original Message-----
From: Dave Watts [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 10:44 AM
To: CF-Talk
Subject: RE: CFMX 'bug'? Easy to crash CFMAIL.
> Re #1: Doesn't putting a try/catch around the cfmail do the
> trick? That way you don't have to validate the email yourself...
> just let cfmail fail if it wants to.
>
> If you put the try/catch around the entire cfloop (or cfoutput)
> of a query then Yes, it will abort the whole job. But if you put
> the cftry/cfcatch around only the cfmail then you can do whatever
> error recovery you want. One easy way is to set
> variables.DidEmailWork = true above the cftry/cfmail and set
> variables.DidEmailWork = false in the cfcatch. Then do any good/no
> good handling outside of the cfttry using that variable to decide
> what happened.
Unfortunately, this approach isn't as clear when you're using a query with
your CFMAIL tag itself; when you do that, it automatically loops over your
recordset, and if any record within that recordset has an invalid address,
the whole thing will fail at that point.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/ <http://www.figleaf.com/>
voice: (202) 797-5496
fax: (202) 797-5444
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
