c# call a method whenever another method ends? -

although question might sound stupid @ first glance, please hear me out.

c#'s get{} , set{} methods increadibly usefull in situations when not know how porgramming goals evolve while build code. enjoyed freedom many time , wonder if there similar methods in bit different light.

as working in gamedev, common practice extend/update/improve existing code day-in day-out. therefore, 1 of patterns taught myself follow never use "return" statement more once in of methods.

the reason why able write @ bottom of method , sure line have written called 100% of time once method ends.

here example:

    public void update()     {         updatemovement();           if (isincapacitated)             return;          if (isinventoryopened)         {             updateinventory();             return;         }          if (input.hasaction(actions.fire))         {             fire();             return;         }         else if (input.hasaction(actions.move))         {             move(input.axis);             return;         }       } 

now imagine method called dozens of times in many places across entirety of project. , next day decide need call updatephysics() method @ end of update() method. in case there 4 returns, worse in reality.

then imagine such decesions happen several times day every day. bad planning may say? might agree you, think freedom of development essential in modern coding. don't think should kill trying anticipate every turn project might take before start writing code.

one way insure problems 1 described above never happen rewrite method follows:

    public void update()     {         updatemovement();           if (!isincapacitated)         {             if (isinventoryopened)             {                 updateinventory();             }             else             {                 if (input.hasaction(actions.fire))                 {                     fire();                 }                 else if (input.hasaction(actions.move))                 {                     move(input.axis);                 }             }         }      } 

in case can add line @ bottom , sure called nomatter what.

so wanted ask if there approach allow placing "return"-s wherever wish while still being able add code @ bottom of method time. maybe there form of syntax in c# you? or maybe there better coding practice eliminates such problem?

update: started receiving answers, realized need clarify things bit.

1. 'try/catch/finally' overkill - never use them. have severe performance penalty on catch(), screw 'edit , continue' feature in visual studio , ugly.

2. idealy need able access local variables in update() method code decide add @ end of method,

3. when wrote question, had answer - nesting. second code sample has no returns and, therefore can add code bottom of method , work 100% of time, while able use local variables. nesting bad though, , why here searching better solution.

update 2: mistaken try/catch because did not know can skip catch alongside it's performance penalties , have finally. however, solution still worse nesting solution provided in question, because in newly added finally block no longer can use return statements. can whatever want when write method first time, once extend - nesting.

using try/finally block should work;

    public void update()     {         try         {             updatemovement();               if (isincapacitated)                 return;              if (isinventoryopened)             {                 updateinventory();                 return;             }              if (input.hasaction(actions.fire))             {                 fire();                 return;             }             else if (input.hasaction(actions.move))             {                 move(input.axis);                 return;             }         }                 {             //this run, no matter return value         }     } 

the performance costs of using try/finally (not try/catch!) minimal

you cannot use return in block;

if able return different value block, value returned, whatever outcome of instructions above. wouldn't make sense..