Exception Handling & Metadata

Metadata is a funny thing... In an effort to make the complex simple we often go down this road of building a generic-meta-data-driven-solution-thingy and end up shooting ourselves in the foot.  For example, COM+ has support for transactional semantics which are controlled by meta-data.  This is all well and good until someone who doesn’t understand the implications of changing these semantics decides to change them.


The idea was pure goodness but the implementation broke down because we did not think of the difference between developer oriented meta-data and admin oriented meta-data.  The first problem is that once you take the meta-data out of compiled code, you have placed it into a realm where it becomes “configurable” by the administrator who is like a “god” on that production machine.  You can write memos email, comments etc. but nothing can prevent that admin from changing the meta-data once it leaves the confines of your assembly.


The first decision point we need to consider is what makes meta-data admin oriented vs. developer oriented.  Both will have an effect on program execution and for good reason but in my mind there are certain things that should never be left up to the admin.  The problem is that there is no clear way to draw that line.


You could say...


Anything that can break the developer’s fundamental assumptions should not be left in the hands of the admin.


The admin can control a great number of things

-          The install location

-          The privileges, memory pool size etc.


But there are some things that the developer assumes when writing their code

-          Transactional semantics

-          Exception behavior


Some folks who were reviewing our upcoming Enterprise Library complained that the new Exception Handling application block externalizes the exception handling behavior into admin configurable meta-data.  They said that this use of meta-data clearly crosses the line and...I have to agree.  I must say I should have known better or thought through this more deeply.


My first thought was to make this meta-data read only at deployment time.  Effective but easily overridden by “god”.  Then it hit me that the only way I can make meta-data safe at runtime and in a form that even “god” won’t mess with is to put it into an assembly.


There are a couple of ways I can think of right off the bat to do this...

1.       Attributes

2.       Static structures


The more I thought about our configuration system I realized that it would be possible to create a config provider who wrote config to a static structure but read it from a compiled assembly thus creating a read only assembly based store for safe meta-data storage.


Now is this strange or what?  Who knows it could be fun.  I’m going to explore solutions for both of these in the coming days.

Comments (3)

  1. Barry Gervin says:

    Yeah, I share the same thoughts. I was a bit freaked the first time I delved into the CMAB. Do we really want to allow admins to change the location/provider of config data? Seems very scary.

  2. edjez says:

    Exactly! – A lot about it is acheiving separation of concerns…

    I’m writing a post commenting on this now.

Skip to main content