http://code.google.com/p/elmah/source/detail?r=686

Modified:
  /wiki/ErrorFiltering.wiki

=======================================
--- /wiki/ErrorFiltering.wiki   Mon Aug 17 13:03:10 2009
+++ /wiki/ErrorFiltering.wiki   Tue Oct 13 10:44:18 2009
@@ -106,7 +106,7 @@
  </elmah>
  }}}

-In the above example, there is a single _assertion_ that will be true when  
the `HttpStatusCode` _equals_ the integer value `404`. There are a lot of  
components at work here so let's dissect this a bit more. ELMAH comes with  
a number of built-in assertions and you can even add your own. The most  
interesting of the assertions test their environment or context for a  
condition. If the condition is met, the assertion outcome is _true_. The  
_context_ is usually the exception that is being raised and the HTTP  
transaction running its course. Both of these are available to the handler  
of the `Filtering` event as properties of the `ExceptionFilterEventArgs`.  
The `ErrorFilterModule` takes these two and adds a few more helper  
properties that are subsequently available as the total context for all  
assertions. The `<equal>` assertion above has a `binding` attribute that is  
actually a data-binding expression that you already know. It is the very  
same expression and syntax you specify to the `Eval` method when  
data-binding within the server-side markup of ASP.NET pages and user  
controls. This expression is evaluated against the context so naturally  
`HttpStatusCode` is a property of the context. The assertion evaluates the  
expression and uses the resulting value to compare against the literal  
given in the `value` attribute. To compare apples to apples and oranges to  
oranges, you have to specify the type of the value expected from the  
binding expression as well as that of the text in the `value` attribute.  
That is the purpose of the `type` attribute, which can be one of the  
`TypeCode` enumeration members. Consequently, the current set of  
_comparison assertions_ are limited to primitive types represented by the  
`TypeCode` members (except `Empty`, `DBNull` and `Object`). This may seem  
limiting at first but it will suffice the majority of filtering you will  
need. For exotic cases, you can always write your own assertions. If you  
omit the `type` attribute then the value type of `String` is assumed.  
Finally, if the comparison succeeds, the assertion flags true and the  
exception is eventually dismissed. With this explanation in mind, here is a  
quick recap of what happens in the above example. First `HttpStatusCode` is  
evaluated against the filter context. Its result is converted to a 32-bit  
integer and compared against the value 404. If they equal, the assertion  
tells the the `ErrorFilterModule` that the exception matches the condition  
for dismissal.
+In the above example, there is a single _assertion_ that will be true when  
the `HttpStatusCode` _equals_ the integer value `404`. There are a lot of  
components at work here so let's dissect this a bit more. ELMAH comes with  
a number of built-in assertions and you can even add your own. The most  
interesting of the assertions test their environment or context for a  
condition. If the condition is met, the assertion outcome is _true_. The  
_context_ is usually the exception that is being raised and the HTTP  
transaction running its course. Both of these are available to the handler  
of the `Filtering` event as properties of the `ExceptionFilterEventArgs`.  
The `ErrorFilterModule` takes these two and adds a few more helper  
properties that are subsequently available as the total context for all  
assertions. The `<equal>` assertion above has a `binding` attribute that is  
actually a data-binding expression that you already know. It is the very  
same expression and syntax you specify to the `Eval` method when  
data-binding within the server-side markup of ASP.NET pages and user  
controls. This expression is evaluated against the context so naturally  
`HttpStatusCode` is a property of the context. The assertion evaluates the  
expression and uses the resulting value to compare against the literal  
given in the `value` attribute. To compare apples to apples and oranges to  
oranges, you have to specify the type of the value expected from the  
binding expression as well as that of the text in the `value` attribute.  
That is the purpose of the `type` attribute, which can be one of the  
<tt>[http://msdn.microsoft.com/en-us/library/system.typecode.aspx  
TypeCode]</tt> enumeration members. Consequently, the current set of  
_comparison assertions_ are limited to primitive types represented by the  
`TypeCode` members (except `Empty`, `DBNull` and `Object`). This may seem  
limiting at first but it will suffice the majority of filtering you will  
need. For exotic cases, you can always write your own assertions. If you  
omit the `type` attribute then the value type of `String` is assumed.  
Finally, if the comparison succeeds, the assertion flags true and the  
exception is eventually dismissed. With this explanation in mind, here is a  
quick recap of what happens in the above example. First `HttpStatusCode` is  
evaluated against the filter context. Its result is converted to a 32-bit  
integer and compared against the value 404. If they equal, the assertion  
tells the the `ErrorFilterModule` that the exception matches the condition  
for dismissal.

  As mentioned earlier, ELMAH ships with several built-in assertions and you  
can use them together to create complex conditions. For example, here the  
`<and>`, `<greater>` and `<lesser>` assertions are used together to filter  
all exceptions where the HTTP status code for the response falls in the  
integer range 400 to 499 (inclusive).