Unless you have some specific reason to catch the exception closer to the point of failure (even if it is just to rethrow the exception with a clearer or more application-specific error message), the service layer is a good place to handle this sort of thing.
On Nov 14, 2007 8:18 AM, Alan Livie <[EMAIL PROTECTED]> wrote: > > As good as unit testing is, I wanted some good error handling inside > CFC's when things go badly wrong. > > At first I used try/catch around DAO's methods and inside the > <cfcatch> I used a NotificationService to send an email to 'support' > and return false to the service CFC that called it. > > I then realised that having the DAO use the NotificationService was > again giving it a responsibility it shouldn't have. > > So I changed the DAO by removing the <cftry><cfcatch> and let it throw > an error. I then put the <cftry><cfcatch> around the service cfc > method that called the DAO and have the service use > NotificationService in the <cfcatch> to send the email (and pager > message possibly on some of the business-critical cfc's) > > I feel more comfortable with this as I think the Service is the best > place to do application-specific tasks rather than have my domain > cfc's do this. > > I also noted Martin Fowler's description of a service layer (from > Patterns of Enterprise Application Architecture ) suggesting this was > the best place for application-specific jobs, making the domain > objects more reusable as a result. > > Do others agree? > > PS This is a good list. I'm quite good at starting discussions then > letting the experts finish them :-) Thanks everyone! > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
