I havent tested this but im assuming this would work:
if you encounter an error in your cfc you call a <cfthrow
type="myApp.mycustomException" message="something stuffed">
ensuring you have <ctry> around you call in your *.cfm file you can then do
something like this
<cftry>
<cfinvoke ...................
<cfcatch type="myApp.myCustomException" >
<p><cfoutput>#CFCATCH.MESSAGE#</cfoutpt></p>
</cfcatch>
</cftry>
the point of having a throws attribtue in your CFC would be you could then
make sure you have handled all the exceptions your cfc method may throw.
Pat
"Scott Barnes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
> On that throws idea,
>
> In the old days when i mixed my presentation layer in with business logic,
i
> used to be able to catch DSNS that are either down or nolonger there
> (webcentral had a nice habbit of moving shit around).. and so i used to
log
> in, and show to the world WEBCENTRAL STUFFED OUR SITE.. error :D
>
> I can now log it with CFC's (of course) but i'd be interested in seeing
how
> people push "presentation layer" logic back out from the CFC logic(s).
>
> (ie keepin in tow with MVC methodology.. in that at no point should any
HTML
> be inside a CFC at all).
>
> So Insert your theories here as i'm all ears.
>
> Scott.
>
>
> "Pat Branley" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > One thing I think would be good is a THROWS attribute on each method in
> the
> > component. That way you would be forced in some situations to put
> > try/catches around you code.
> >
> > This would be really good when using/creating 3rd party components.
> >
> > Being a java programmer, Id also like the ability to define interfaces.
> This
> > would also give you a work around of not being able to do multiple
> > inheritence by implementing multiple interfaces.
> >
> > Pat
> >
> >
> > "Steve Onnis" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > >
> > >
> > > I am here by starting a wishlist for CFCs
> > >
> > > Here are my few items.
> > >
> > > 1- Ability to declaire multiple types in the "Type" attribute of the
> > > CFARGUMENT tag. Either by using multiple tags or using a list within
> the
> > > attribute.
> > >
> > > 2- Ability to dynamicly populate the "ROLES" attribute of the
CFFUNCTION
> > > tag.
> > >
> > > 3- Friendlier CFINVOKE syntax so you dont have to create the object
> ovewr
> > > and over for methods in the same CFC.
> > > eg.
> > >
> > > <cfinvoke component="componentsDemo.components.maths">
> > > <cfinvokemethod method="Average" returnVar="Bla">
> > > <cfinvokeargument name="Numbers" value="#Numbers#">
> > > </cfinvokemethod>
> > > <cfinvokemethod method="Sum" returnVar="Bla2">
> > > <cfinvokeargument name="Calculation" value="#Calculate#">
> > > </cfinvokemethod>
> > > </cfinvoke>
> > >
> > >
> > > I know you can do this by using the CreateObject and <CFOBJECT
methods,
> > but
> > > if they give us these tags to use, maybe they should be a little more
> > > flexible
> > >
> > > my 2 cents
> > >
> > > Steve Onnis
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
