Using Attributes to Handle Exceptions?

  • Thread starter Thread starter Steve - DND
  • Start date Start date
S

Steve - DND

Is it possible to do something like what this chapter excerpt shows, except
for just a regular non-remoting bunch of code?

http://www.microsoft.com/mspress/books/sampchap/6172a.asp

The reason I ask, is that I have implemented everything as is from the
chapter above, but none of my attribute code gets called. I have the
attribute tag declared right above my class, such that it looks like...

[ExceptionLogging("filepath...")]
public class Foo() {...

Unfortunately nothing seems to happen. I have tried setting breakpoints in
the code, but it never seems to hit. Exceptions are being thrown, but
they're not being caught by this facility. This is leading me to believe
that the solution above is only for remoting. Does anyone have any tips on
making it work for non-remoting code, or articles that show an implement of
this. I believe this all takes after Aspect Oriented Programming, and seems
like it could be hugely beneficial for error handling and such.

Thanks,
Steve
 
Hi Steve,

An attribute attached to a class does nothing in itself. There needs to be
code somewhere that looks at that attribute and does things based on it. In
the remoting sample you refer to it is the remoting infrastructure that
interprets the attribute.

To make your ExceptionLogging attribute do what you want it to do, you need
to write the code to do it. Your code can find out if the attribute is there
via reflection. In pseudo-code:

void DoThings(ClassThatMightHaveTheExceptionLoggingAttribute o)
{
try
{
o.DoSomething();
}
catch (Exception ex)
{
// figure out if 'o' has the attribute (via reflection)
object[] typeAttrs = o.GetType().GetCustomAttributes();
if (typeAttrs != null)
{
foreach (System.Attribute attr in typeAttrs)
{
if (attr is ExceptionLoggingAttribute)
{
LogException(ex,
((ExceptionLoggingAttribute)attr).FilePath);
break;
}
}
}
}
}

Regards,
Sami
 
I'm a bit confused, as I assumed that an attribute automatically performed
it's functionality, prior to, or after a function call or some such. Are you
saying I need to implement the pseudo-code below somewhere in my normal
classes? If so, where exactly is it put? Is it put in every function that
makes use of the attribute, or in just one place?

Thanks,
Steve
 
Actually I have found this to not be entirely true. There is no additional
wire-up needed(at least if you inherit from ContextBoundObject).
Unfortunately, my problem seems to stem from the fact that the method being
called is static, and for some reason it doesn't trigger any of the
attribute's work. Once I made the class instantiable, and called the method
that way, the attribute code worked as expected. So I guess my real problem
now is how to get attribute code to work on static methods. Any thoughts on
that one?

Steve
 
Steve - DND said:
I'm a bit confused, as I assumed that an attribute automatically performed
it's functionality, prior to, or after a function call or some such. Are you
saying I need to implement the pseudo-code below somewhere in my normal
classes? If so, where exactly is it put? Is it put in every function that
makes use of the attribute, or in just one place?
Click to expand...

In the remoting case it may seem that the attributes perform things
automatically but this is only because the remoting infrastructure does all
the work for you.

The details of how and where you write the code that interprets the
attributes depend on your application, I'm afraid there is no generic
catch-all advice here. For a sample of a system that uses attributes, see
e.g., the NUnit open source unit testing framework at http://www.nunit.org/.

For example, NUnit has a feature that allows you to attach an
ExpectedException attribute to a test case method. This attribute causes the
test case to succeed only if the expected exception is thrown when the test
case runs. When NUnit runs the test case, it looks if the method has this
attribute, and if it does, NUnit runs it within a try/catch and declares the
test case success only if the exception was thrown. (I'm sorry I can't think
of a better example - NUnit might be a bit complicated if you're just
getting started with C#).

Sami
 
Oh, I see. If you derive from ContextBoundObject, it does provide the call
interception functionality and it does the work for you. I was under the
impression you wanted to have this functionality in classes that do not
inherit from ContextBoundObject (class Foo in your original post was not
derived from ContextBoundObject).

Anyway, as to your question about static methods of ContextBoundObjects, I'm
not sure about the answer to that one. My guess is that the context is, as
the name says, bound to an instance and hence the context bound
functionality does not apply to static methods. That is also the case with
e.g., the SynchronizationAttribute that you can use for synchronizing method
calls - it does not apply to static methods.

Sami
 
Back
Top