Javascript es un mal lenguaje para los emprendedores: evítalo

[pijoprogre]

Estoy trabajando en una cosa y miren el lío que tengo. Infierno de callbacks.... hallludaaaaa!!!

Infinitos callbacks que llaman a otro callback que llaman a otro callback hasta el punto de requerir una pantalla con una resolución de 2000x890000, que puede estar parametrizado o puede no estarlo. Imaginaos lo complicado que es trazar mentalmente todo esto. Cada vez que dejas la programación para otro momento has de detenerte unos minutos para hacerte un nuevo mapa mental. Ya no sé ni qué carajos hago

Otro problema que tendréis será el manejo de this, recordad que es diferente según el contexto. Esto significa que deberéis conservar una referencia al this originario usando self. Es una pesadilla.

¿Qué otro problema hay? El manejo de errores (Exception handling) es horrible, pésimo. Simplemente todo ha de ir entre try...catch y usar a conveniencia throw para disparar errores y capturarlos antes de que tiren la aplicación.

En definitiva, evítenlo en la medida de lo posible. Especialmente si necesitan algo fiable y robusto.

 

[El grito]

No es el javascript. Eres tú. Ese código es malísimo.

 

[aminomepilla]

No soy un experto en javascript, no te ofendas, pero viendo el código el problema no es el lenguaje...

El último snippet es para enmarcarlo ¿que prentendes hacer?

try{
  throw "Error in IndexQuery";  /*¿lanzas una excepción para recogerla abajo de modo incondicional!!!?*/
} catch(err){
     self.Error(err); /*¿Es un constructor que no construye? ¿porque esta el método en mayúsculas? ¿es un objeto Error que quieres lanzar?*/ 
}

/* no se que pretendes hacer pero esto es equivalente ... */

self.Error("Error in IndexQuery");

Y estructura un poco el programa, objetos, funciones etc no tiene que ser todo inline y las excepciones no recuperables se lanzan a las capas superiores sin controlar, la capa superior se hará cargo: log, limpieza, etc ...

 

[pijoprogre]

No soy un experto en javascript, no te ofendas, pero viendo el código el problema no es el lenguaje...

El último snippet es para enmarcarlo ¿que prentendes hacer?

try{
throw "Error in IndexQuery"; /*¿lanzas una excepción para recogerla abajo de modo incondicional!!!?*/
} catch /*donde esta el (err)!!!?*/ {
self.Error(err) /*¿Es un constructor que no construye? ¿porque esta el método en mayúsculas? ¿es un objeto Error que quieres lanzar?*/
}

no se que pretendes hacer pero esto es equivalente ...

self.Error("Error in IndexQuery") o esto


Y estructura un poco el programa, objetos, funciones etc no tiene que ser todo inline y las excepciones no recuperables se lanzan a las capas superiores sin controlar, la capa superior se hará cargo: log, limpieza, etc ...

Te explico. Es una plantilla. Escogí esa porción con fin ilustrativo. En realidad los trys abarcan varios segmentos del código y según la comprobación se hace throw a un tipo u otro de error para ser capturado (fíjate en el throw de la primera imagen)

La mayoría de errores en js se disparan intencionalmente con la finalidad de ser capturados.

Hay otras formas, como usar Error.

Por cierto. self.Error no es lo mismo que this.Error, ya que en el contexto de función (contexto local) this no hace referencia al contexto global donde está el objeto Error.

Por cierto, los callbacks no son eludibles. Son de uso obligatorio en casos como este. El flujo de ejecución es siempre más rápido que el tiempo de latencia de respuesta de la base de datos.

 

[aminomepilla]

Y es un lenguaje que esta bastante bien, muy potente, pero no es nada fácil.

---------- Post added 12-mar-2014 at 08:29 ----------

A ver, el primer throw del primer snippet parece correcto, pero el ultimo snippet no tiene sentido, ese donde lanzas la excepcion para capturarla inmediatamente.

 

[pijoprogre]

Y es un lenguaje que esta bastante bien, muy potente, pero no es nada fácil.

---------- Post added 12-mar-2014 at 08:29 ----------

A ver, el primer throw del primer snippet parece correcto, pero el ultimo snippet no tiene sentido, ese donde lanzas la excepcion para capturarla inmediatamente.

Porque el último es con fin ilustrativo. No tengo ninguna porción de código donde pueda resumirse en una sola imagen el inicio del try, los throws y el catch.

Es rápido, no potente.

He quitado la imagen. No pensé que pudiera malinterpretarse.

 

[Salvado_por_los_pelos]

Pequeño Padawan...

Simplifica el código. Javascript hace muchas cosas bien, pero si lo complicas, es posible que te tires horas en hacerlo funcionar.

Yo suelo utilizarlo mucho en combinación con php y todas mis aplicaciones van de miedo.

 

[JyQ]

¿Pero qué ostras va a ser el lenguaje??????

Siempre es una mala metodología si el lenguaje es de uso común.

Usa jquery y deja de complicar los callbacks.

 

[pijoprogre]

Pequeño Padawan...

Simplifica el código. Javascript hace muchas cosas bien, pero si lo complicas, es posible que te tires horas en hacerlo funcionar.

Yo suelo utilizarlo mucho en combinación con php y todas mis aplicaciones van de miedo.

¿Pero qué ostras va a ser el lenguaje??????

Siempre es una mala metodología si el lenguaje es de uso común.

Usa jquery y deja de complicar los callbacks.

Es javascript del lado del servidor.

Un saludo.

 

[luckyLuck]

Creo que el problema es tu codigo, no el lenguage...

 

[OberOst]

Hoygan, ¿ si aprendo el jacascri este podre jakiar cosas por internes ?

 

[Carbonilla]

Dejad de llamar emprendedores a los programadores e informáticos, hombre ya.

 

[luckyLuck]

Dejad de llamar emprendedores a los programadores en informáticos, hombre ya.

Hombre, depende de a lo que se dedique ese programador.

 

[kudeiro]

Dejad de llamar emprendedores a los programadores e informáticos, hombre ya.

y eso por qué? no todos son desgraciados esclavizados por la carnica o multinacional de turno