Feda /dev/ - No Javascript allowed

No sé en qué clase de tugurios trabajan, pero vamos, que "hagan putaditas" a un becario que se va, pues ya te puedes imaginar

Mañana presentamos demo del proyecto a ver si nos echan a todos a la calle o seguimos para adelante. Consta de dos partes y somos tres en el team, dos se encargan de integrar la más compleja y yo la otra. Ellos acaban antes que yo y mergean a develop. Yo hago pull de develop, mergeo con mi rama, pruebo mi integración (matiz importante), hago el MR, el Jenkins en verde, merge a develop, etc. Eso ayer.

Hoy hacemos un dry run y su parte no va. Panic ensues.

Después de dar mil vueltas veo que Git me la ha liado cuadrada porque entre esto, que estaba en develop:

@Component

Y esto, que estaba en mi rama:

//@Component

Ha elegido lo de mi rama. El mismo Git que se agobia cuando tiene el mismo import en dos líneas diferentes, que te marca como conflict un cambio en una línea que no has tocado, ha mergeado esto sin pestañear.

#29653 claro que me rio, el Jackson no te obliga a nada eh. Eso te esta diciendo que ese codigo puede lanzar esas 2 excepciones.

Jackson no te obliga a nada, usas el sneaky simplemente para no declarar el exception throwing en la firma del método

#29657 #29656 El tema es que ese readValue está dentro de un override del método onMessage() de la clase SQSSessionCallbackScheduler (que igual te suena lo de SQS, es una clase de la librería de Amazon XD) y no se puede poner un throws en la signature del método porque está sobreescrito. ¿Se podría usar un try-catch? Pues puede, no sé. Pero esto es una demo y no nos íbamos a calentar la cabeza con analizar eso ahora.

#29658 Bueno, es para esas cosas que se usa el sneaky throw

Lo que te lleva al punto de que el puto sistema de manejo de excepciones en Java es un auténtico desastre desde su concepción, por mucho que Gosling diga lo contrario

.

soy el unico que se pone cachondo con el gif de lecherito?

#29668 Tanto te gustan los perritos calientes? el original es este