Executing code at function exit

[Danny Liberty]

Hi,

I would like to be able to execute code when a function exits. In c++ I
would have created an object on the stack in the function entry point
and it's destructor would be called when the function exits as
following:
void func()
{
MyObj obj;
.....
} <- Destructor code of MyObj called here.

I could be more explicit by writing this code in C#:
void func()
{
.....DoSomething...
ExitFunction();
}

But note that as opposed to the C++ code, ExitFunction() is not called
in the case an exception was thrown from func(). I could use the same
code in C#, but since the GC is not determinstic my ExitFunction() code
wouldn't be called in time.

You may ask why I want code to run at the function exit if the
instruction flow hasn't reached the end of the code, but this could be
very useful for building a logging infrastructure where I could show
the flow of function calls in my application.

Any suggestions how this can be solved?

Thanks,

Danny

 

[José Joye]

Place a try - finally statement within your function.
In that sense, you can be sure that even in case of throw the finally is
executed:
void func()
{
try {
....DoSomething...
}
finally{
ExitFunction();
}

}

- José

 

[Danny Liberty]

Of course, but since I'm writing a logging framework I would like to
minimize the amount of code required to do this. If I have to put a try
/ catch statement for the entire scope of every function it would make
my code extremely "dirty"...

 

[Greg Young]

I would recommend looking at AOP (if not aop atleast the concept of using a
dynamic proxy to apply these items).

Luckily you picked a logging example, there are about 1000000 examples of
AOP doing logging

Cheers,

Greg
Of course, but since I'm writing a logging framework I would like to
minimize the amount of code required to do this. If I have to put a try
/ catch statement for the entire scope of every function it would make
my code extremely "dirty"...

 

[Danny Liberty]

Actually I did look into AOP. Most implementations use ContextBound and
IMessageSink to intercept the call to the function. Generally this
works, but if the function throws an exception it cannot be caught by
the original caller since the "real" caller of the function is actually
the transparent proxy created by using the message sink. In other
words, the function is being called from SyncProcessMessage() and since
the exception is not caught there it is not propogated to the original
caller. A workaround could be to put the code in SyncProcessMessage()
in a try-catch block, but this would have a great impact on performance
(not to mention the price I've already paid for inheriting from
ContextBound).

Actually, it looks like .Net lacks support for an efficient AOP
implementation.
Current implementations for .net seem to be awkward. The use of objects
and interfaces originaly designed for remoting to achieve this seems to
me like a huge and ugly workaround.

Anyway, suggested solutions will be greatly appreciated

Danny