last day (15 days later) » 

2:32 AM
hola @Stefan
disculpa que venga tarde, estoy en unas clases de Java
 
Hola
ningun problema
 
perfecto
 
la razón porque pienso que hay casos en que la NPE no es necesariamente malo es la capa de información extra
ejemplo
quiero leer datos de una BD
caso uno: devuelvo el resultado ue tiene la BD o un resultado vacío si la BD no tiene el dato
en caso de error devuelvo null, implicando un error
ahora en todas otras partes del codigo puedo decidir si compruebo el resultado null, sabiendo que mi programa puede vivir con el error
 
así es, programación defensiva
lidio con eso todos los días =\
 
pero donde no lo hago (por olvido, negligencia, o porque prefiero una salida altiro) me sale con la excepcion
PERO:
 
2:36 AM
ajá, generando dolores de cabeza sobretodo cuando el sistema está en producción
 
tambien digo que en este caso es mucho más claro de nisiquiera atrapar las excepciónes reales
entonces, prefiero la NPE sobre ofuscar un nivel de información, pero prefería aun más de diferenciar por una variedad de excepciones más concretos
 
yo prefiero devolver objetos nulos
 
la NPE no comprobado según yo no debería sobrevivir el "smoke test"
yo prefiero lo que funciona mejor en el caso concreto
a veces el dato es tan volatil ue no me molesta mucho si aparece o no en este momento
en estos casos me importa más que el software no se caie
 
bueno, al usuario final no le parece nada agradable ver un mensaje que explota en su aplicación diciendo Error NPE
 
hay otros casos en que lo encuentro más recomendable que el sistema se caie sobre que el sistema sigue con datos corruptos
 
2:39 AM
sobretodo porque el programador (tú, yo, X) se olvidó de ponerlo
o que una transacción pesada se corte de golpe porque un objeto es nulo
 
jajajaja
cierto
 
eso tb me ha pasado varias veces
 
la NPE es una puta barrata
 
es más, la semana pasada me ocurrió
en un proceso que genera reportes
 
me recuerda a cosas peores de la epoca en que desarrollé en MS commercial basic con rutinas en assembler
 
2:40 AM
pero no está hecho a prueba de NPEs
 
"String space corrupt during garbage collect" ;)
 
entonces sucedía que habían personas a las que se les quería generar un reporte y no tenían registrado su nombre, saltaba el NPE
 
estos hacen dolores de cabeza, cuando te das cuenta que había un error cuando el gc falla
 
así es =\
los NPEs no los considero buenos
ni en Java ni en ningún otro lenguaje
 
yo tampoco
 
2:42 AM
en ese lado me agrada Optional
 
pero los prefiero sobre ninguna excepcion
por lo menos te dan un stacktrace
 
principalmente Optional#ofNullable
los cuales luego te permiten anidarlo con Optional#orElse
 
si, lo ubico. muy parecido a futuros
 
yo sigo prefiriendo los objetos vacíos sobre los nulos
 
en todo caso hay una tendencia en la programación de trabajar más con "estados imaginarios"
 
2:44 AM
principalmente porque a diferencia de un null no controlado, con los objetos vacíos no necesariamente dejaré un stacktrace horrible gigante que me llena el log (más horrible si es por la iteración de miles de elementos, el log se vuelve pesadísimo con todos esos stacktraces impresos allí)
 
igual tengo que confesar que soy tan dinosaurio que me incomoda un poco el estado indefinido en la informatica
 
pero en su lugar puedo logearlo como WARN
advertencia, ojo, etc
 
concuerdo, pero eso tambien depende de la disciplina con que se supervisa o controla un sistema
yo pienso que espacio en el disco para un par de stack traces es barrato
 
en particular me gusta esta explicación
1922
A: Avoiding != null statements

cletusThis to me sounds like a reasonably common problem that junior to intermediate developers tend to face at some point: they either don't know or don't trust the contracts they are participating in and defensively overcheck for nulls. Additionally, when writing their own code, they tend to rely on...

 
encontrar errores sin buenos logs es una pesadilla
 
2:45 AM
se vuelve un problema cuando tus logs zipeados comienzan a pesar 100 MBs o más
comen mucho espacio en disco innecesario
 
y en el caso que es un error que occure cada vez en tanto no más, es poco reproducible pero causa daño, estas en el desierto con un simple "warn"
 
y lo peor es que estás zipeando texto plano
ni siquiera binarios
hay aplicaciones que están hechas sobre plataformas
y leer los NPEs allí y detectarlos es toda una odisea
x ejm pentaho
 
bueno, eso pasa en los logs si tienes muchos catch con el e.printStackTrace() por defecto
 
anda échate a buscar por qué salió NPE
 
no creo en eso
 
2:47 AM
siempre aparece por allí un programador que lo hará
lo he visto
 
en mi mundo, si SE que pasó en un catch y lo puedo corrigir, siguiendo con la pega, no necesito el stackTrace
pero SI quiero uno cuando y donde mi codigo se caie
 
sí, pero algún día dejarás de mantener esa aplicación y vendrá otro que no piensa igual y llenará todo de stacktraces
 
y a veces prefiero qque se caie sobre seguir con datos corruptos
 
y que te muevas a una app donde todo está logueado
bueno, partamos de que un objeto vacío no es nulo y tampoco es data corrupta
es como una cadena vacía ""
 
bueno, pero la basura no es mía ;)
 
2:49 AM
no será tuya pero va al cliente
si programamos pensando en que el cliente hará un carajo con eso, estamos mal
los usuarios son, nos guste o no, los que deciden el éxito de nuestras aplicaciones
 
a ver si te entiendo
 
no importa cuán compleja sea la aplicación, el diseño, las horas de amanecida, de trabajo en equipo, la metodología (waterfall, scrum, xp, lean, lo que sea)
 
yo digo que yo trato de evitar stacktrace mientras queda claro porque termino en el catch
 
lo que importa al final del día es que el usuario use la app y esté cómodo
yo digo que lo principal es que la aplicación esté limpia para los usuarios y para nosotros los devs
 
y solamente cuando decido que no atrapar la excepción (o atraparla y luego terminar programaticamente) quiero lo más información ue posible sobe lo que pasó
 
2:51 AM
usar objetos vacíos en lugar de nulos nos ayuda a evitar mostrar/manejar errores que no esperamos que aparezcan y en su lugar tratar estos casos de manera que ayuden a ambos grupos
 
en que cambia esto de ser un buen concepto dependiente qquien mantiene mi codigo despues?
peligroso, segun yo
 
ok, vamos al ejemplo de la aplicación que vemos
imaginemos que el programador (ni tú ni yo) es novato, está aprendiendo
ok, si no encuentra datos, elige devolver un nulo
 
evitar errores que no hemos anticipados es bueno mientras sabes que no pasa nada malo al fin y que lo unico en que logras con sobredocumentarlos es tener un cliente histerico suena bien
 
ejecuta su query, si no hay datos devuelve null, de lo contrario devuelve una lista con los elementos
manda esta lista a un atributo del request
luego en el JSP manda a pintar la data con <c:forEach>
 
pero que pasa si desarrollas un software que controla maquinaria, quizás las ruedas de un avion?
 
2:53 AM
momento, veré a mis alumnos
 
Saludos :)
 
gracias
no, ellos no están leyendo esta conversación
pero les haré presente :P
 
Hablando de eso, eres profe de informatica?
 
están resolviendo un ejercicio, me paseo de rato en rato para ver cómo van, si tienen dificultades, si no compila, si compila pero tienen problemas de ejecución, etc
enseño en un instituto, curso de programación en Java
 
Donde en este mundo?
 
2:57 AM
ahorita estamos viendo struts2 (lo sé, es viejo, es antiguo, ya casi no se usa, es legado, pero está en la currícula y no puedo cambiarla, debo seguirla)
así es, en este mundo donde tú y yo vivimos
ok, continuemos con el caso
el programador solo manda a mostrar la lista que ha registrado como atributo de request
si el dao le devuelve nulo
 
Jajaja, mi pregunta en realidad era curiosidad donde vives
 
oh ya xD
yo vivo en Lima, Perú
 
porque aqui en chile ya es casi las 12pm, es bien tarde para clases de java
 
aquí estamos a 2 horas de diferencia
 
clases nocturnas?
 
2:59 AM
justo la próxima semana voy a trabajar para un proyecto de Chile
 
que bueno, que se acostumbren altiro a horarios extraños :D
 
como hay las horas de diferencia y allá trabajan desde las 9 am, aquí serán las 7, así que tendré que mega madrugar
 
y disculpa mi castellano mediocre, yo nací en alemánia y llegué a chile con 5 palabras de español 9 años pasados, el resto fue autoaprendizaje
 
oh qué genial
parece que fueses latino
al menos se te lee y entiende muy bien
tanto en el chat como en las publicaciones que haces
por cierto, veo buenas publicaciones tuyas, me alegra tener compañeros así en el sitio
 
jajajaja, lo he escuchado. hago un esfuerzo, no es muy cortes de dejar los demas adivinar de que uno habla
gracias, tu también me llamaste la atención por buenos conocimientos practicos
 
3:02 AM
por cierto, he visto que has estado editando publicaciones, principalmente preguntas
te pido por favor revises esta publicación de meta
8
Q: ¿Qué formato deberían tener los nombres de tecnologías/lenguajes?

Alvaro MontoroEn SOes los nombres propios de tecnologías o lenguajes de programación se pueden encontrar de múltiples maneras, por ejemplo: python Python Python Python Python Yo normalmente uso el primero o el segundo, pero he visto que mucha gente utiliza el último. ¿Hay alguna norma de estilo sobre cuál ...

 
no me permite editarlo
 
no puedes acceder al enlace?
 
el autor debería referirse a "la manera" y decir "utilizando"
acceder si, pero no puedo editar la pregunta
 
ah
no te pido que la edites, te pido que la leas :)
 
ahhhh :D
bueno, un poco más ortografía tambien hubiera ayudado a la pregunta :D
ok
python
eso sería tu preferencia?
 
3:07 AM
mi preferencia es Ruby, me parece más sencillo
pero ahora trabajo con Java
un momento, debo explicar unas cosas
tardaré en responder
 
jajaja, me referí al estilo, no al idioma
backtick para codigo
y reservar negritas para palabras claves
aparte de la discusión, hay algo como una recomendación que se debe usar para cosas como nombres de clases, métodos etc.?
 
3:33 AM
Bueno, me retiro para hoy día ya es tarde aquí
 
 
1 hour later…
4:48 AM
@StefanNolde eso es código
nombres de clases, métodos, funciones, nombres de variables, etc, es código
así que usemos battick
 
5:11 AM
Charla interesante.. Gracias por compartirla
 

  last day (15 days later) »