Manejo de errores simple Javascript

      Uno de los grandes problemas con javascript es el manejo de errores. Muchas veces uno se queda dando vueltas tratando de entender por que algo funciona y lo que sucede es que silenciosamente javascript falló y nadie se enteró de nada. O, en otros casos, una funcion nuestra que ejecutó JQuery falló y se ve el scope de jquery en version min y nos queremos cortar la sexualidad.

     Otras veces, con todas las funciones locas para agregar features de funcional, hay un gran nivel de indireccion y wrappeo de funciones, lo que lleva a un debug complicado.

    Por otro lados siempre es bueno tener el manejo de errores en un solo punto, después de todo DRY se aplica a todo, y los varios manejos de errores no traen mas que dolores de cabeza.


    En fin, siguiendo con la linea de pensamiento de orden superior podemos pensar en una funcion que se use en la definicion de las funciones que pueden tirar un error.

function e (fn, st) {
   if (st == null) st = alert;
   return function () {
        try {fn.apply(null, arguments)}
        catch (err) { st(err); }
   }
}

  Como bien se puede ver esta funcion devuelve la funcion metida adentro de un try catch definido y con una estrategia de manejo de error pasada por parametro y con alert como estrategia por defecto.

  Ahora con agregar un objeto tercero que maneje errores tenemos una definición robusta. :)

 Un ejemplo de uso puede ser

   var funcionManejada = e( function () { throw "ejemplo"}  );
   funcionManejada(); 


  Les prometo que si encuentro como bajar monadas felices a Jscript voy a hacer la versión monádica, que es todavía mas poderosa.


Ahora, como aplicamos esto a javascript orientado a objetos?
Se me ocurre velozmente una forma similar con el siguiente boceto

function ErrorMixin (object) {
    for(k in object){
     if(this.isMethod(object[k]) {
         object[k] = e(object[k]);
    }
  }
}

function objetito () {
   ErrorMixin(this);
   
}


Faltaria definir isMethod, que es una huevada pero no me acuerdo los strings :P Igual esta claro que este mixin es bastante pobre por que se aplica sobre todos los metodos del objeto. Se me ocurre tambien que podrían anotarse o podrían definirse con una expresion regular y alguna convencion adhoc.


Buep, enjoy your weekend my friend. Por mi lado me voy a escaviar y comer fondue a la farmacia

Mixins y javascript

Para terminar el día del blog (ahora paso a hacer catarsis en otro blog) voy a tirar un par de ideas de compartimiento en javascript.

 Antes que nada voy a remarcar que escucho mucho 'javascript es una mierda' 'javascript no es orientado a objetos' y otras paparruchadas.

Javascript no es una mierda, la mierda es tener que programar una pagina y que se vea bien en internet explorer 6.

A javascript lo unico que le agregaría para orientación a objetos seria la palabra clave object para no tener que definir un objeto con function. Pero no me pondría a hablar de forradas como clases, herencia y eso, después de todo es un lenguaje orientado a objetos con otras forma de armado de objetos, mas manual si, pero mucho mas poderosa.


 Empecemos un poco por, ¿Por qué existen las clases?

Simple, tengo un monton de objetos que van a tener el mismo comportamiento, defino una plantilla y después los creo creandolos a partir de esta plantilla.

Si nos ponemos a pensar que lo importante en la orientación a objetos son los objetos, entonces en seguida salta a la luz que la clase es una forma de programar menos en ciertos contextos, es una forma de clasificar y ordernar conocimiento que tira una linea fuerte obvia y unidireccional: un objeto puede ser de solo una clase (bajo la idea original de clases) y en general esta clase esta muy relacionada con la clasificación que tiene esta 'idea' en el contexto de nuestro negocio.

>> y entonces... la herencia? 
>> la herencia es para poder compartir aun mas código, y para mantener la clasificación en varios niveles, permitiendo mejores abstracciones que las que daría una linea tan dura como ser una clasificación única. (por ejemplo, si solo puediera tener una clasificación no se me ocurriria pensar en la clase animal domestico, iria directamente a tener las clases perro y gato) 


>>Pero javascript no tiene una buena forma de ordenar y compartir codigo
>> Eso lo decís por que estas pensando en clases cuando debieras estar pensando en compartir código.


Hace algunos años apareció la idea de traits / mixins. En lineas generales se trata de compartir codigo entre distintos objetos / clases (segun approach) a un nivel menos estricto que el de clase, permitiendo otras figuras de clasificación que solo el jerarquico de un padre a n hijos (como propusiera en su momento la herencia multiple sin buen recibimiento por la paja mental de los diseñadores de lenguaje a la hora de pensar en la resolución de mensajes).

Probablemente después me cope y haga un articulo para este tema puntual, ahora mismo voy a suponer que lo tienen al menos de oido. Sino busquen por google o esperen a mañana o pasado que escriba y lo suba.

Aca les dejo una idea de mixin en javascript


function BaseComponentMixin (object) {
         object.log = function (message) { console.log (message); };
         object.renderOver = function (componentId) {
                                 $("#"+componentId).append(object.getHtml());
         };
         object.getHtml = function (){
                                  alert("El objeto mixeado debe implementar getHtml()");
        };
}

function HtmlExample (object)  {
       object.getHtml = function () { return "<b> hola mundo </b>"; } ;
}


function  Componente () {
        BaseComponentMixin(this);
        HtmlExample(this);
}

var comp = new Componente();
comp.log("hola");
comp.renderOver("unIDdeDiv");



Que ganamos con esto? Ahora tenemos codigo ordenado por cierta 'habilidad' y podemos organizarlo en mas formas que solo clases. Eso nos permite reutilizar mas código y llegar a abstracciones mas locas que en un codigo sin orden y que en un codigo con un orden demasiado estricto.



>> pero.. es javascript, para que me quiero romper tanto la cabeza? es solo la pantallita
>> Si bueno, la pantallita te puede traer muchos problemas y mucha repetición de código. Tambien hay que tener en cuenta que los sitios evolucionan a ser de una sola pagina por lo que ya no es mas un poquito de javascript para animar los menues, sino que tambien necesitamos java para el comportamiento que ya no va a generar el servidor.
>> Bue.. no se.. igual yo voy a seguir haciendo clases aunque sean mixins
>> No seas pelotudo, usa los mixins como mixins y las clases como clases. No acotes tu pensamiento a la costumbre y no pronuncies opiniones tan cerradas sin haber probado si quiera una vez lo que vas a críticar.




Finalmente si sos usuario de Javascript por ahí te hace ruido que en el mixin haya usado objeto.selector = function ().... en vez de hacerlo vía objeto.Prototype.selector, la razón por la que lo hago así es por que me gusta la posibilidad de elegir que objetos estan mixineados y que objetos no.