c# - Are there standard naming conventions for this example of The Template Method Pattern? -

i want create abstract class common exception handling pattern:

public abstract class widget {     public ifoo createfoo()     {         try         {             createfoounsafe();         }         catch(exception ex)         {             throw new widgetexception(ex, moredata, evenmoar);         }     }      protected abstract ifoo createfoounsafe(); } 

the intention have standard exception handling pattern across deriving objects. abstract createfoounsafe() method should not expected contain exception handling. implementations single line of return new foo(...)

what want know whether there standard naming conventions associated pattern, particularly exception-throwing code expected?

the names above seem appropriate, not entirely without smell.

the short answer no.

there no convention in template pattern designate type , when exception thrown. kind of information included in section of documentation per msdn. using c# , xml comments can generate such documentation.

i'm under impression there might naming convention in place template pattern sans referencing exception handling. understand it, naming might this:

public abstract class widget {     public void performaction()     {         this.performactionimpl();     }      protected virtual void performactionimpl(){} } 

where impl shorthand "implementation". don't naming style don't use i'm sure i've read somewhere semi authoritative that "the" way it.

i wouldn't use of in case seem want either factory or abstractfactory.

..

with regard exception query, seems me code little inside out tho disagree of other comments depending on circumstances.

wrap , throw entirely valid exception handling technique.

the additional context provided type of exception may enough route exception appropriate handler. i.e. you've transformed exception widgetexception 1 expect has context within application. might enough.

where you've done wrapping disagree with.

i catching wrapping , throwing from within subclass implementation of virtual method subclass going have enough understanding of it's doing know whether exception indeed widgetexception , therefore wrap , throw or little more hairy should propagate.

the code stands making massive assumptions cause of exception , in sense rendering use of custom exception next useless. i.e. widgetexception.

so while believe type alone enough contextualise exception dont believe code making decision in right place. understand motivation behind implementation you've chosen seems tasty shortcut, "the myth of knowing base class" mere fact declared abstract should provide significant clue class intended ignorant design.

so respect crosscutting concern of exception handling don't think should looking pattern make life easier rather framework abstract guff away.

for example enterprise library.