[SOLUCIONADO] Excepción Null o NO ELIMINA

[gswarlus]

Hola, qué tal a todos? No puedo resolver un problema que veo bastante básico. No encuentro el rollo así que posteo para ver si me pueden dar una mano.

Las clases objeto que uso son: BinaryNode, Key y Error (es uno propio, no el de java.lang). El código sigue así:

Código:

	// Es un método para eliminación de un nodo de un Árbol BB, entra una clave "Key" y un manejo de errores.
	public void delete(Key key, Error e) {
		// Si el objeto (árbol) está vacío, establece un error y sale.
		if (this.isEmpty()) {
			e.setCode(7);
			System.out.println(e.getMessage());
		// Si no está vacío, llama a un método privado que recibe un "BinaryNode" para trabajar con él (ser eliminado).
		} else
			// El método "search" busca el nodo y trae la referencia.
			this.deleteMethod(this.search(this.root, key, e));
	}

Hasta acá vamos bien.. el siguiente método recurrente, contiene 4 subcasos, siempre y cuando el nodo que estamos trabajando NO sea nulo (caso de corte). El problema está en solo el siguiente caso:

Código:

	// Método privado para eliminar el nodo.
	private void deleteMethod(BinaryNode node) {
		if (node != null) {
			if (node.getLeft() == null && node.getRight() == null) {
				// El "BinaryNode" tiene un atributo "Element" contenedor de un objeto. Entonces, aquí lo establezco en nulo, ocasionando un NullPointerException.
				node.setElement(null);
	// ..el código continúa, aunque no es de importancia.

Si en lugar de establecerlo en null al elemento, hago lo siguiente:

Código:

node = null

el nodo nunca se elimina.

¿Alguna solución?

Gracias, saludos!!

[Fuzzylog]

pues le asignas un valor al nodo y luego lo eliminas...

[gswarlus]

El tema es ese (si es que te entendí).. la parte de eliminación falla.
Igualmente, ya tengo una posible solución, no es la que me gusta, la dejo para "resolver" el thread.

Guardar el enlace del padre (i.e, el nodo que enlaza a "node"), y luego establecerlo en nulo desde esa posición anterior (padre).
No lo probé, aunque veo que es una solución fehaciente. El problema (en mi código) es que recibo en el método privado un solo nodo (el nodo en cuestión), desde otro método privado (llamado "search") que me otorga el enlace al nodo en cuestión. Habría que redefinir todo.

Saludos!

[GreenEyed]

Aparte del tema, ya que eliminar es funcionalidad propia que implementas tú y entonces es difícil decir cómo debería funcionar, la recomendación en lenguajes como Java es que para notificar errores se usen excepciones, y no pasar como parametro objetos y luego tener que comprobar códigos de error etc.

S!

[gswarlus]

Iniciado por GreenEyed

Aparte del tema, ya que eliminar es funcionalidad propia que implementas tú y entonces es difícil decir cómo debería funcionar, la recomendación en lenguajes como Java es que para notificar errores se usen excepciones, y no pasar como parametro objetos y luego tener que comprobar códigos de error etc.

S!

Gracias, el tema es que en las implementaciones (para la Universidad) que tengo que hacer.. no nos dejan hacerlo! :S Jejeje...
Otro dato curioso:

Código:

while (CONDICIÓN) {
  if (CONDICIÓN2)
    break;
  else
    LO QUE SEA..
}

No nos dejan tampoco usar ese "break" porque dicen que bla bla bla no es "limpio" para la lectura.. y que el día de mañana, bla bla bla.. son sandeces!! :P Jejeje..

[GreenEyed]

Hombre, lo del break en un IF no lo habia visto nunca.... no sería para un switch? Al fin y al cabo, en un if no hace falta nada el break.

Y lo de que no os dejen usar Excepciones en Java es... sin comentarios... mejor no digo ná. .

[gswarlus]

Iniciado por GreenEyed

Hombre, lo del break en un IF no lo habia visto nunca.... no sería para un switch? Al fin y al cabo, en un if no hace falta nada el break.

Y lo de que no os dejen usar Excepciones en Java es... sin comentarios... mejor no digo ná. .

Jejeje.. sí, tal cual, sin comentarios.. yo tampoco tengo! Jajaja... las normas, son las normas ( ? ) :P

Con respecto al "break", te pongo un ejemplo:

Código:

for (int i = 0; i < 32; i++)
   if (CONDICIÓN)
      LO QUE SEA..
   else
      i = 32;
 

Es decir, poniendo el índice en el tope o con cualquier otro valor que haga que la condición (i < 32) no se cumpla, logro salir de la iteración. Cambiemos ahora el código:

Código:

for (int i = 0; i < 32; i++)
   if (CONDICIÓN)
      LO QUE SEA..
   else
      break;
 

El "break" corta cualquier iteración, uso el "if" porque sino no tendría sentido entrar en una iteración y cortarla.. entonces dada "x" condición, corto la iteración.. cuando la condición no es de tipo numérica (i < 32, por ejemplo), a veces es bien útil usar el "break", aunque no es necesario, para mí sigue siendo más limpio el corte que forzar al algoritmo llegar a su tope y que la condición no se cumpla o poner una bandera (while (CONDICIÓN && flag == true) ó bien while (CONDICIÓN && flag)).

En el terreno hay MUCHAS formas de hacerlo! Jejeje.. me quedo con el "break" (aunque no lo pueda usar en la clase! ;)).

Saludos!

[GreenEyed]

Ahí sí que no estoy de acuerdo, por que las instrucciones que provocan cortes bruscos en el flujo de un programa no deberían usarse más que para situaciones excepcionales que deban realmente cortar por lo sano, como son por definicion las excepciones.

No es el programa funcione mal, pero a nivel conceptual es más fácil seguir un programa que no tiene estos saltos bruscos que uno que si los tiene, ya que te permite abstraer mentalmente el código en bloques más manejables sin tener todos los detalles en la cabeza, y eso es muy importante en programas grandes.

Por ejemplo, viendo el código que muestras, a la hora de entenderlo, a nivel global es más fácil pensar "esto se repite 32 veces cambiando el indice" que tener que pensar "no se cuantas veces se puede repetir por que puede que dentro haya un break que me lo haga saltar a la segunda iteración". El primer caso te permite entender el bloque global de un vistazo mirando la estructura de control superior, en el segundo tienes que mirar todo el contenido en detalle. Y quizá ahora te parezca una sandez, pero cuando te toca mirar y mantener el código de otra persona, esas cosas se agradecen y hacen que los programas tengan menos errores.

Por eso mismo las excepciones nunca se han de usar para controlar el flujo normal de un programa, si no únicamente para situaciones excepcionales de error. A lo mejor es eso lo que quieren conseguir con que no las useis, aunque no dejarlas usar para nada me parece excesivo.

S!

[gswarlus]

Síp.. tal cual esa fue la misma explicación que nos dan a los alumnos.

Ahora yo te digo lo siguiente: estás obviando un pequeño detalle.. si yo pongo el índice en i = 32 es EXACTAMENTE un corte brusco.. ídem estaría produciendo el break. En tales casos, puede ser que ninguno de los dos llegue nunca a completar 32 ciclos.

Pero no hablemos de ciclos repetidos mediante condiciones de índice.. hablemos por ejemplo de lo siguiente:

Código:

while (nodo != null) {
   if (nodo.getDato().equals(datoEntrada)
      nodo = nodo.getEnlace();
   else
      nodo = null;
}
 

Comparémoslo con el siguiente (OJO! Son todas pequeñas cosas que se me van ocurriendo, debido a programas que he hecho en el pasado, no es que sean exactamente los mismos casos :D):

Código:

while (nodo != null) {
   if (nodo.getDato().equals(datoEntrada)
      nodo = nodo.getEnlace();
   else
      break;
}
 

¿Me entendés a lo que voy? Para mí es más legible (sea código mío o de otro: otro dato, NUNCA vi un código (de Java) tan prolijo como el mío, en indentación y cierta documentación y coherencia) ver un "break" a forzar una salida del tipo anterior (primer ejemplo).

Aunque son formas y formas, jeje.. te aseguro que mi código lo entendería cualquiera! Por esto de la prolijidad y demás.. :D

Bien, gracias por contestar. Saludos!!

[GreenEyed]

Iniciado por gswarlus

...estás obviando un pequeño detalle.. si yo pongo el índice en i = 32 es EXACTAMENTE un corte brusco.. ídem estaría produciendo el break. En tales casos, puede ser que ninguno de los dos llegue nunca a completar 32 ciclos.

Bueno, es que poner el indice a 32 para salir de forma brusca es algo que tampoco se debería hacer .

Iniciado por gswarlus

Pero no hablemos de ciclos repetidos mediante condiciones de índice.. hablemos por ejemplo de lo siguiente:

Código:

while (nodo != null) {
   if (nodo.getDato().equals(datoEntrada)
      nodo = nodo.getEnlace();
   else
      nodo = null;
}
 

Comparémoslo con el siguiente (OJO! Son todas pequeñas cosas que se me van ocurriendo, debido a programas que he hecho en el pasado, no es que sean exactamente los mismos casos :D):

Código:

while (nodo != null) {
   if (nodo.getDato().equals(datoEntrada)
      nodo = nodo.getEnlace();
   else
      break;
}
 

¿Me entendés a lo que voy? Para mí es más legible.

En realidad no lo es, ya que en el primero la salida se produce al fallar la condición de salida del while, alto nivel, y en el segundo caso la salida se puede producir en cualquier punto dentro del while por que cortas el flujo y le obligas a salir. Si sales con un break... ¿al acabar el while puedes asegurar que nodo es null? No. Entonces no es más claro.

Iniciado por gswarlus

(sea código mío o de otro: otro dato, NUNCA vi un código (de Java) tan prolijo como el mío, en indentación y cierta documentación y coherencia) ver un "break" a forzar una salida del tipo anterior (primer ejemplo).

Una nunca puede ser juez de su propio codigo ya que encaja con el esquema mental de uno mismo y todo es "natural, lógico y clarísimo". En palabras de algunos expertos en programación: "programa como si el que tuviera que mantener tu código fuera un maníaco asesino que sabe donde vives".

Iniciado por gswarlus

Aunque son formas y formas, jeje.. te aseguro que mi código lo entendería cualquiera! Por esto de la prolijidad y demás.. :D

Por supuesto, es cuestión de forma y no tienes por que hacerles ningún caso. Pero estas cosas no se las sacan los expertos en programación de la manga, si no que son producto de la experiencia de años. Y es difícil de entender si tus programas sólo los ves tú y són para clase, pero en una empresa te asegura que las probabilidades de que usar breaks dé problemas al que viene detrás es muchísimo más alta que si no los usas.

Por poner un ejemplo, ahora mismo están pensando añadir closures a Java y lo primero que han descartado es permitir que un return/break dentro de una closure produzca una salida del método o estructura de control que llama a la closure... precisamente para evitar que se puedan usar como tu dices.

Pero bueno, tampoco te caera un rayo si los usas... al menos después de haber aprobado esa asignatura

[gswarlus]

No quisiera entrar en tanto detalle jeje.. aunque:

En realidad no lo es, ya que en el primero la salida se produce al fallar la condición de salida del while, alto nivel, y en el segundo caso la salida se puede producir en cualquier punto dentro del while por que cortas el flujo y le obligas a salir. Si sales con un break... ¿al acabar el while puedes asegurar que nodo es null? No. Entonces no es más claro.

Fue un ejemplo sin ningún tipo de argumento, solo se me ocurrió, podría ni siquiera necesitar si el nodo es nulo. Hablo de claridad lingüística, no de eficiencia.. la eficiencia es un punto y a parte, aunque en este caso, tampoco es más eficiente forzar el índice a la salida abrupta que el break.

Una nunca puede ser juez de su propio codigo ya que encaja con el esquema mental de uno mismo y todo es "natural, lógico y clarísimo". En palabras de algunos expertos en programación: "programa como si el que tuviera que mantener tu código fuera un maníaco asesino que sabe donde vives".

Lo lamento, disiento en muchos puntos: no sé si se trata de ser "juez", es una palabra medio engorrosa, aunque si me preguntás qué tal me parece a mí, no digo que es perfecto, digo que es lo mejor que YO puedo hacer.. y está muy bien, y mejor que TODOS los que he visto, como te decía.. siempre sin alejarnos de lo léxico, de la escritura. Es decir, mirá mi ortografía por ejemplo, NO voy a dejar de ser mi propio "juez", porque sé que mi ortografía es excelente (sin presumir, eh! :D). Vos decís que para cada uno todo es "natural, lógico y clarísimo", yo no me juzgo a mí mismo.. lo digo por otros que han leído mis códigos, y porque hay personas que escriben algo y luego no lo entienden.. entonces, no es tan "natural, lógico y clarísimo" para ellos tampoco.

Por supuesto, es cuestión de forma y no tienes por que hacerles ningún caso. Pero estas cosas no se las sacan los expertos en programación de la manga, si no que son producto de la experiencia de años. Y es difícil de entender si tus programas sólo los ves tú y són para clase, pero en una empresa te asegura que las probabilidades de que usar breaks dé problemas al que viene detrás es muchísimo más alta que si no los usas.

En este caso particular son para "clase".. ya he trabajado en empresas trabajando, y te aseguro que soy muy eficiente y eficaz. xD

[quote]Pero bueno, tampoco te caera un rayo si los usas... al menos después de haber aprobado esa asignatura [/QUOTE
Igualmente, te entiendo.. estamos hablando muy en el aire.. jeje.. y se desvió el thread! :S

Gracias por las respuestas, saludos!!

[GreenEyed]

Bueno, tampoco pasa nada. Yo sólo decía que esa restricción que os ponen sí tiene una base, ya que todos los expertos así lo recomiendan, a diferencia del no usar excepciones para nada que no lo he visto recomendar nunca si no más bien al contrario.

Y respecto a lo de juez, no lo decía en el sentido que pareces entender si no en el de valorar uno mismo. Y no, uno no puede valorar si su código es claro, lógico y natural, de la misma forma que uno no puede "valorar" si sus hijos son guapos por que "a todo el mundo" los suyos le parecen guapísimos y la gente que te comenta cosas es para decirte lo guapos que son, no para decirte que parecen un mono . Hay excepciones en los extremos, claro, pero es así.

De todas formas, también es bueno practicar a programar con restricciones y así si algún día te toca trabajar en un equipo que tenga las suyas, ya te has acostumbrado a hacer las cosas de distintas formas. Cuando programes tú para ti, lo puedes hacer como quieras. .

S!

[gswarlus]

Jejejeje.. okay okay!

Saludos!