En la plataforma .NET existen distintas formas de hacer que una llamada a un método sea omitida bajo determinadas circunstancias. Por ejemplo, los métodos parciales permiten, en C# 3.0 y VB 9.0, que el compilador omita la llamada a funciones no implementadas. También existe la posibilidad de utilizar las clásicas directivas (como #if… #endif ) para incluir código cuando existan constantes de compilación.

Es menos conocida, sin embargo, la existencia del atributo ConditionalAttribute, que aplicado a un método hace que las llamadas a éste no sean incluidas en el ensamblado si no existe la constante de compilación cuyo nombre se indica en el parámetro.

Por ejemplo, explorando un poco el espacio de nombres System.Diagnostics, vemos que todos los métodos de la clase Debug, están adornados por este atributo así:

   1: [Conditional("DEBUG")]

   2: public static void WriteLine(string message)

   3: {

   4:     TraceInternal.WriteLine(message);

   5: }

Ahora, imaginad que tenemos un código que usa esta clase, por ejemplo de la siguiente manera:

   1: public static void Main(string[] args)

   2: {

   3:     for(int i=0; i < 1000; i++)

   4:     {

   5:         Debug.WriteLine("Iteración " + i);

   6:         ProcesaAlgoComplejo(i);

   7:         int j = ProcesaOtraCosa(i);

   8:         Debug.WriteLine("Obtenido " + j);

   9:         // ...

  10:     }

  11: }

Si compilamos en modo “debug” (o simplemente está definida la constante de compilación con dicho nombre), las llamadas a estos métodos serán omitidas en el ensamblado resultante, por lo que el código finalmente generado será totalmente equivalente a:

   1: public static void Main(string[] args)

   2: {

   3:     for(int i=0; i < 1000; i++)

   4:     {

   5:         ProcesaAlgoComplejo(i);

   6:         int j = ProcesaOtraCosa(i);

   7:         // ...

   8:     }

   9: }

Pero ojo, que se omiten tanto las llamadas al método como la evaluación de sus parámetros, y esto puede provocar errores difíciles de detectar. Por ejemplo, el siguiente código daría lugar a un bucle infinito de los de toda la vida ;-) si compilamos en modo “release”; sin embargo, compilando en “debug” funcionaría correctamente:

   1: int j = 0;

   2: while (j < 100)

   3: {

   4:     Console.WriteLine("Hey " + j);

   5:     Debug.WriteLine("Procesado " + (j++));  // <-- Esta línea desaparece cuando

   6:                                             //     compilamos en modo release!

   7: }

Aunque en el anterior ejemplo estamos jugando con la constante predefinida DEBUG, este atributo podemos utilizarlo con otras constantes, tanto existentes como personalizadas. Como muestra, podéis echar un vistazo a la definición de la clase System.Diagnostics.Trace, que vincula el uso de sus métodos a la existencia de la constante TRACE:

   1: public sealed class Trace

   2: {

   3:     // ...

   4:  

   5:     private Trace();

   6:     [Conditional("TRACE")]

   7:     public static void Assert(bool condition);

   8:     [Conditional("TRACE")]

   9:     public static void Assert(bool condition, string message);

  10:     [Conditional("TRACE")]

  11:     public static void Assert(bool condition, string message, string detailMessage);

  12:     [Conditional("TRACE")]

  13:     public static void Close();

  14:     [Conditional("TRACE")]

  15:     public static void Fail(string message);

  16:     [Conditional("TRACE")]

  17:     public static void Fail(string message, string detailMessage);

  18:     [Conditional("TRACE")]

  19:     public static void Flush();

  20:     [Conditional("TRACE")]

  21:  

  22:     //...

  23: }

Si vais a utilizar el atributo sobre vuestros métodos, condicionándolos a la existencia de constantes de compilación personalizadas, recordad que las constantes podéis definirlas:

• desde las propiedades del proyecto en el IDE
• en la línea de comandos del compilador (por ejemplo, /define:LOG)
• variables de entorno del sistema operativo (set LOG=1)
• en directivas sobre vuestro propio código (directiva #define LOG)

Eso sí, tened en cuenta que el método siempre será compilado e introducido en el ensamblado, son las invocaciones a éste las que son omitidas en caso de no existir la constante indicada.

Hay que tener en cuenta las siguientes observaciones para el uso del atributo Conditional:

• Los métodos a los que se aplica no pueden tener tipo de retorno, es decir, serán void. Esto tiene bastante sentido, si pensamos en los efectos laterales que podría causar la desaparición de una invocación tras la cual se haga uso del valor retornado.
• Sólo se pueden aplicar a métodos en clases o estructuras. Nada de interfaces (¡tampoco tendría mucho sentido!).
• Si un método virtual está marcado como Conditional, las reescrituras de éste realizadas desde clases descendientes también lo estarán.  Es bastante lógico, puesto que así se mantienen las dependencias íntegras.
• Si el atributo se aplica a un método, éste no puede ser un reemplazo del comportamiento de un antecesor (o sea, que no puede ser un override). También resulta muy lógico.

En resumen, se trata de un buen método para incluir código condicional en nuestros desarrollos, dependiente del contexto de compilación, evitando tener que usar directivas #if… #endif. Pero no lo olvidéis: cuidado con los efectos laterales citados.

Publicado en: Variable not found.

El control de errores en aplicaciones web es fundamental si queremos ofrecer un interfaz robusto y amigable para los usuarios en cualquier situación. No hay nada más frustrante para un usuario que una pantalla de error con contenidos indescifrables y que no le aportan alternativas de salida.

El framework ASP.NET MVC nos ofrece mecanismos de control de errores muy potentes basada en la utilización del atributo HandleError, el cual definirá la vista que será mostrada al usuario cuando se produzca alguna excepción no controlada en el código de los controladores, siempre que en el web.config se haya activado el uso de errores personalizados mediante la propiedad CustomErrors.

En este post vamos a profundizar en el uso del atributo HandleError, comentando cómo se implementa en el controlador, su ámbito de actuación, los parámetros que ofrece y la forma de crear las vistas para mostrar los errores de forma amigable.

El controlador

HandleError puede ser declarado tanto a nivel de clase (controlador) como a nivel de acción. En el primer caso, se establecerá el comportamiento general para todas las acciones del controlador, mientras que en el segundo será aplicable sólo a la acción a la que se asocie el atributo:

// Control de errores a nivel de clase de controlador, 
// que será aplicado a todas las acciones del mismo.
[HandleError()]
public class HomeController : Controller
{
    ...
}

// Control de errores a nivel de acción concreta...
[HandleError(ExceptionType=typeof(ArgumentException), View="ArgumentError")]
public ActionResult Calculate(int a, int b)
{
  ViewData["results"] = calculateSomething();
  return View();
}

En realidad, el comportamiento definido en el atributo HandleError a nivel de clase también se aplicará a los errores generados por las vistas u otros resultados (ActionResult) retornados por los controladores. Es decir, sobre el segundo de los ejemplos anteriores, la vista “ArgumentError” (que existirá en un archivo llamado ArgumentError.aspx) será invocada cuando la excepción ArgumentException sea lanzada bien por el propio controlador, o bien por la vista “Calculate” que retorna por defecto.

Un último detalle sobre esto: el atributo HandleError puede ser especificado tantas veces como necesitemos sobre la misma acción o controlador, indicando comportamientos para distintos tipos de excepción. El atributo que se tendrá en cuenta cuando se produzca un error será el primero que se encuentre cuyo tipo de excepción (parámetro ExceptionType) sea compatible con la excepción lanzada.

El manejador de errores que se empleará en una acción será el primero que corresponda al tipo de excepción producida, teniendo en cuenta tanto los atributos que adornan la acción como los que acompañan a su controlador, y siempre según un orden preestablecido.

Veamos con más detenimiento los parámetros que admite la declaración del atributo.

Parámetros de HandleError

        [HandleError(
            ExceptionType=typeof(DivisionByZero), 
            View="ErrorPersonalizado", 
            Master="MaestraErrores",
            Order = 0)
        ]
        public ActionResult Index()
        ...

• ExceptionType permite indicar el tipo de excepción que se pretende controlar. Por defecto, el sistema entenderá que la regla se refiere al tipo base Exception, por lo que se aplicará a todos los errores que se generen, pues todas las excepciones heredan de esta clase.
• View, el nombre de la vista que será mostrada al usuario. Por defecto se tomará el valor “Error”, por eso en la plantilla de proyectos ASP.NET MVC ya existe una vista con este nombre.
• Master, la página maestra con la que será renderizada la vista, independientemente de lo que tenga declarado ésta.
• Order, un valor numérico (por defecto –1, el más prioritario) que indica la prioridad de aplicación de esta regla cuando el sistema encuentre varios atributos HandleError aplicables al mismo elemento y que puedan presentar conflictos. Los valores más pequeños, Por ejemplo, si no se indicara este parámetro en el siguiente caso, el resultado dependería del orden de declaración, lo cual no es demasiado recomendable:
  

  [HandleError(Order=10, View="ErrorGenerico")]
  public class HomeController : Controller
  {
    ...
    [HandleError (ExceptionType=typeof(DivisionByZero),
                  View="OperacionIncorrecta", Order=1)]
    public ActionResult Calculate()
    ...

  
  Como puede intuirse, esto hará que en caso de producirse una división por cero, se muestre la vista “OperacionIncorrecta” y no la “ErrorGenerico”.

Cada vez que utilicemos HandleError es conveniente tener muy en cuenta la prioridad (definida en la propiedad Order), el alcance (las excepciones a tratar, definidas en la propiedad ExceptionType), así como los valores por defecto en cada caso. Esto evitará comportamientos misteriosos del sistema una vez se produzcan errores en tiempo de ejecución.

Acceso desde la vista a la información del error

Ya hemos comentado anteriormente que la vista que será mostrada a los usuarios cuando se produzca un error será la indicada en el parámetro View del atributo HandleError, o la vista "Error", si este parámetro no es informado. Sea cual sea, el archivo nombredevista.aspx deberá estar localizable por el motor de vistas en el momento de su lanzamiento (por cierto, si no te gustan las ubicaciones por defecto, puedes ver cómo modificar la forma en la que se buscan las vistas en este post).

La vista de un error es una página .aspx normal, como una vista más de la web, pero con la particularidad de que puede recibir información sobre el error que ha provocado su presentación. De hecho, se trata de una vista tipada que hereda de ViewPage<System.Web.Mvc.HandleErrorInfo>, de forma que  la propiedad Model será del tipo HandleErrorInfo, clase que nos ofrece completa información sobre el origen del problema:

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" 
    Inherits="System.Web.Mvc.ViewPage<System.Web.Mvc.HandleErrorInfo>" %>

<asp:Content ID="errorTitle" ContentPlaceHolderID="TitleContent" runat="server">
    Error en el sistema
</asp:Content>
<asp:Content ID="errorContent" ContentPlaceHolderID="MainContent" runat="server">
    <h2>
        Ups, se ha producido un ligero inconveniente...
    </h2>
    <p>
        La acción <%= Model.ActionName %>  
        del controlador <%= Model.ControllerName %>
        ha lanzado la excepción <%= Model.Exception.GetType().Name %> con
        el mensaje "<%= Model.Exception.Message %>".
    </p>
</asp:Content>

A pesar de no ser un buen ejemplo como pantalla del error amigable para el usuario ;-), el código anterior ilustra cómo es posible acceder desde la vista a los datos del contexto del error proporcionados por el entorno, y cómo la clase HandleErrorInfo nos ofrece una información sobre la acción en la que se ha lanzado la excepción, el controlador en el que se encuentra la misma, y lo más interesante, nos ofrece en la propiedad Exception la excepción producida, por lo que tendremos acceso a su tipo, descripción e incluso al estado de la pila de llamadas en el momento de producirse el error.

Publicado en: www.variablenotfound.com

0. Antes de empezar…

• en primer lugar, el propio software Live Writer, más que nada porque necesitamos referenciar algunos de sus ensamblados, y por ir probando el complemento durante el desarrollo.
• en segundo lugar, Visual Studio 2005 o 2008, aunque sea una edición express. Este desarrollo vamos a realizarlo en C#, pero la traducción a Visual Basic .NET sería trivial.

1. Preparación del proyecto

• La primera referencia es al ensamblado que contiene el API de Live Writer, que podéis encontrar en el directorio de instalación de la herramienta. El  archivo a incluir es WindowsLive.Writer.Api.dll .
• La segunda es a System.Windows.Forms. Hay que tener en cuenta que Live Writer es una herramienta de escritorio, y esta referencia es importante para poder interactuar con el mismo.

Otro detalle más que nos va a facilitar las cosas: vamos a indicar a Visual Studio que el resultado de la compilación lo copie en el directorio de plugins de Live Writer. Para ello, lo único que tenemos que hacer es acudir a las propiedades del proyecto, pestaña “eventos de generación” e incluir la siguiente orden en el cuadro “línea de comandos del evento posterior a la generación” (obviamente, modificando la ruta si es necesario):

XCOPY /D /Y /R "$(TargetPath)" "C:\Archivos de Programa\Windows Live\Writer\Plugins\"

2. Escribimos la clase principal

  public class CodeTag: ContentSource
  {
     public override DialogResult CreateContent(IWin32Window dialogOwner, 
                                               ref string content)
    {
      if (string.IsNullOrEmpty(content))
          content = "YourCodeHere";
      
      content = "<code>" + content + "</code> ";
      return DialogResult.OK;
    }
  }

• Si la variable content viene vacía o con valor nulo, es que el complemento ha sido lanzado en modo inserción, es decir, no existía ningún texto seleccionado y por lo tanto lo que se pretende es añadir las etiquetas de código para introducir posteriormente contenido. Como puede observarse en el código, lo que se hace en este caso es insertar las etiquetas <code> con un texto arbitrario para que el usuario lo modifique a su antojo más adelante.
• En caso contrario, si la variable content trae algún contenido, lo que se hace es rodear éste por la apertura y cierre de la etiqueta <code>.

3. Añadimos metadatos

[WriterPlugin("98497c2b-bbfd-4bd1-b343-226f3c9e766b", "Code Tag",
    Description = "Crea etiquetas <code></code> en el contenido",
    PublisherUrl = "http://www.variablenotfound.com")]
[InsertableContentSource("Etiqueta <code>")]
public class CodeTag: ContentSource
{
  [...]
}

• El primer parámetro es un GUID, es decir, un identificador único que debemos generar para el plugin, utilizando este servicio on-line u otras herramientas como la incluida en Visual Studio.
• El segundo parámetro es el nombre del plugin. Es la identificación que aparece en el cuadro de diálogo de configuración de complementos de Live Writer.
• Description permite añadir una descripción textual ampliada del plugin.
• PublisherUrl es una dirección web de referencia al autor. Pura propaganda ;-)

4. Compilamos el proyecto

5. Añadirle un icono al plugin

    [WriterPlugin("98497c2b-bbfd-4bd1-b343-226f3c9e766b", "Code Tag",
        Description = "Crea etiquetas <code></code> en el contenido",
        ImagePath = "CodeTag.bmp",
        PublisherUrl = "http://www.variablenotfound.com")]
    [InsertableContentSource("Etiqueta <code>")]
    public class CodeTag : ContentSource
    {
      [...]
    }

6. O, por si no quieres teclear…

Las lambda como árboles de expresión

  var dobla = a => a * 2; // Error: no se puede asignar
                          // una expresión lambda a una variable
                          // local de tipo implícito.

Definición de árboles con expresiones lambda

  Expression<Func<int, int, int>> media = (a, b) => (a + b) / 2;

  // Árbol de expresión de una función que determina
  // si el parámetro que le llega es par
  Expression<Func<int, bool>> esPar = a => a%2==0;

  // Árbol de expresión de una función 
  // que retorna el máximo de dos números.
  Expression<Func<int, int, int>> maximo =
              (a, b) => a > b ? a:b;

  // Árbol de expresión de una función que
  // retorna un string transformado
  Expression<Func<string, string>> TrimMays = 
              a => a.Trim().ToUpper();

  // Árbol de expresión de una acción 
  // sin parámetros que escribe por consola la fecha y hora.
  Expression<Action> accion =
              () => Console.WriteLine(DateTime.Now); 

  // Suma los n primeros naturales
  Expression<Func<int, int>> expr =
    n => {
           int t = 0;
           for (int i = 1; i <= n; t += i++) ;
           return t;
         };

  // Error CS0834: Una expresión lambda con cuerpo no puede ser 
  // convertida a árbol de expresión

  // Árbol definido con una lambda:
  Expression<Func<int, bool>> esPar = a => a % 2 == 0;

  // Y el mismo árbol definido a mano, 
  // lo que genera el compilador automáticamente:
  ParameterExpression param = Expression.Parameter(typeof(int), "a");
  ConstantExpression dos = Expression.Constant(2, typeof(int));
  ConstantExpression cero = Expression.Constant(0, typeof(int));
  BinaryExpression modulo = Expression.Modulo(param, dos);
  BinaryExpression comparacion = Expression.Equal(modulo, cero);
  Expression<Func<int, bool>> esPar2 =
       Expression.Lambda<Func<int, bool>>(comparacion, param);

Uso de los árboles de expresión

Linq

  // Usando una consulta Linq:
  var datos = from p in productos 
                 where p.Nombre.StartsWith("S")
                 select p;

  // O su equivalente usando 
  // operadores de consulta:
  var datos = productos.Where(p=>p.Nombre.StartsWith("S"));

Cálculo simbólico

  private static Expression Derive(this Expression e, string paramName)
  {
      switch (e.NodeType)
      {
          [...]
          // sum rule
          case ExpressionType.Add:
              {
                  Expression dleft = 
                     ((BinaryExpression) e).Left.Derive(paramName);
                  Expression dright = 
                     ((BinaryExpression) e).Right.Derive(paramName);
                  return Expression.Add(dleft, dright);
              }
          [...]
      }
  }

   Expression<Func<double, double>> 
                funcion = x => x*x;          // f(x)=x^2

  Expression<Func<double, double>> 
                derivada = funcion.Derive(); // f'(x)=2*x

  Console.WriteLine(derivada); // Muestra la función derivada:
                               //    x => ((x * 1) + (1 * x))

ASP.NET MVC

  // Obtiene un enlace al método "ChangePassword"
  // de la clase "AccountController":
  Html.ActionLink("Cambiar clave", "ChangePassword", "Account")

  // Lo mismo, pero usando un árbol de expresión:
  Html.ActionLink<AccountController>
              (acc=>acc.ChangePassword(), "Cambiar clave")

Los árboles de expresión como código ejecutable

  Expression<Func<double, double>> 
                funcion = x => x*x;          // f(x)=x^2

  Expression<Func<double, double>> 
                derivada = funcion.Derive(); // f'(x)=2*x

  // Compilamos la función derivada
  // y obtenemos un delegado a la misma:
  Func<double, double> funcDerivada = derivada.Compile();

  double result = funcDerivada(6); // Obtenemos el valor de la función 
                                   // invocando al delegado con x=6
  Console.WriteLine(result);       // Muestra "12"

¡Y hasta aquí hemos llegado!