After writing my previous post on a modeling-language for exception-management logic I ended up in a fair amount of discussions about the sense (and nonsense) of describing parts of a program in a model *and* treating the model itself as part of the sourcecode.

Aspect orientation and limitations to Object orientation
The dsl-model is nothing more than an aspect oriented programming language. Aspect oriented languages allow for expressing parts of a program in a fashion that does not mix concepts like 'exception handling', 'caching', 'thread synchronization', etc. with the parts that make your program do its work.

In object oriented languages (like c#) it is often hard to write programs that contain the concepts above without cluttering your sourcecode -which referred to as tangling in aop terminology.

Since most applications we write need good exception handling this usually means that we end up mixin our programs code with exception handling logic (which makes the code itself more complex) -or failing to do so consistently (which lowers the quality of a program).

How do Aspect oriented languages solve this problem?
Aspect oriented languages have the concept of a joinpoint. A joinpoint is a descriptor of a point within your program ("before any method prefixed 'Get' is called", "when an unhandled exception occurs within methods x, y, z", "before a exception will be thrown", etc..). These joinpoints allow an aspect oriented language to express all tangling parts of your code to be written down in 1 place, instead of mixing this with the rest of your code with it.

To break it down
The exception management language knows about 
* 1 joinpoint: "when an unhandled exception occurs in method x, y, z"
* How to insert this 1 line of code in a .net assembly ( if ExceptionPolicy.HandleException(e, "xyz") throw; )
* The model in which all the variables are expressed.

Added value:
* It allows you to define all your exception management code in 1 place (and keeping your program code clean)
* It never forgets to enforce best practices (that you might forget yourself using c# as an implementation language -the same way a compiler hides all the pushing and popping of registers when you write c++ code)

Why a modeling language?
Modeling language are straightforward to understand and since Microsoft is putting a lot of effort into having a dsl-toolkit to support the authoring of modelling languages hosted in visual studio, this seemed a neat approach. really, it could be any sort of notation.

Software factories?
Since I think software factories are about working with more appropriate levels of abstraction than 3rd level programming languages provide, I think the exception management languages serves that cause.

No "drag-cows-and-pigs-around-the-screen-diagram", 'just' a simple solution to solve 1 aspect of what makes writing applications an increasingly complex task.

Loss of flexibility?
When working with higher levels of abstraction comes loss of flexibility -right?, right!

To illustrate: When programming c++, you have less control over your memory than when you are writing x86 assembly instructions. But… is this a bad thing? Well it might if you want to squeeze every little drop of performance out of your code, for most scenarios it eases development and increases productivity.

With the flexibility Enterprise Libraries ExceptionHadling block provides from its configuration (yes - this includes adding context to thrown exceptions, replacing exceptions, hiding exceptions and ..whatever) would automatically inserting this code at predefined places in your program be a bad thing? -Well it might if you want some custom tailored exception handling scenario within your code, in most cases it eases development. Does it make having a custom solution in place harder or impossible? No it doesn't (as long as the rest of your program is written in c#).

On a side note: I believe flexibility will be increasingly gained by configuration, not sourcecode - the same way Enterprise Library does.

Next steps with in developing these sorts of models
Yes I would love to release the exception management language asap, though first I would like to solve some practical problems in its current implementation, naming:
1) The classes you drag on the designer surface currently come from the toolbox, which is impractical and should be fixed.
2) References to the classes in your sourcecode are not tracked, which could be solved by annotating them using a code comment similar to "//do not remove the following guid: {xxxxx-xxxxxx-xxxxxx-xxxxx}"

I also figured that having these 2 problems solved in a framework layer, would lower cost of writing new similar dsl's. I could think of a couple, such as:
* Caching, in which you define whether the outcode of a method call should be stored in a (configurable) cache.
* Security, in which you define which methods can be executed by whom, based on roles.
* Tracing/logging, should the execution of this method (and possibly its parameters passed to this method) be logged?
* Instrumentation, should performance counters be incremented every time a method is called? Should wmi events be fired if a certain condition is met?

The above are all examples of aspects that can be mixed into a program without having developers to know about it - they do not mess with the state of a class or alter program flow.

If there are people truly eager to contribute, please let me know.

Modeling the base language
With base language I mean the language your program is written in, all of the above assumes c#.

Big question is: would it be possible to eventually express the way your program behaves in a more specialized language? -I'd say it might. Pragmatic as I am I’d go with first defining models for patterns we currently identify and iteratively discover new patterns in whatever is left.

In the Aspect oriented programming community there are people that believe in something called "Symmetric AOP" - an approach to aspect orientation in which everything is expressed as being an aspect (also the base implementation). Somehow people actually managed to make implementations of such languages, such as HyperJ.

Amen -