🚀 go-pugleaf

>Luego, sobre lo que comentas de gotos "invisibles". No es lo mismo. El goto es
>una transferencia totalmente incondicional y a un lugar no especificado a
>priori. Eso lo convierte en algo muy parecido a una escopeta cargada y de
>gatillo muy sensible.

Yo tambi�n estoy de acuerdo con eso. 

Un manejo de excepciones tipo "try except" como tenemos en Delphi (no
s� el equivalente en Java, algo como try catch?) est� claro que usa
algo parecido a goto, pero tambi�n tenemos muy claro, cuando vemos el
c�digo, qu� es lo que hace, y a donde saltar�a si tiene que saltar. No
sigue las normas de la programaci�n estructurada, pero cumple muy bien
un objetivo de un lenguaje de alto nivel: facilitar las cosas al pobre
"pogramador".

Un exit o return tambi�n rompe la programaci�n ordenadita, pero aqu�
tambi�n tenemos algo muy claro al ver el c�digo: return equivale a
terminar la funci�n. Si vemos una, sabemos que nos lleva al final de
la funci�n.

Otro ejemplo m�s: continue/break tambi�n nos definen claramente qu�
hacen y adonde llevan el flujo del programa.

Esa es la diferencia principal de todas estas funciones con el goto:
el goto nos lleva a vete a saber d�nde, vete a saber qu� le pasa a las
variables... con el resto de pseudo-gotos todo queda bastante
definido.

De todas formas, de los ejemplos que se han ido exponiendo aqu�, en
ninguno veo necesario el goto (al menos, trabajando en Delphi). Por
ejemplo, el que quer�a liberar recursos haciendo

 coge_recursos;
...
 if cond then goto libera;
...
 if cond then goto libera;
...
libera:
 libera_recursos;

en Delphi podr�a quedar algo as� (m�s o menos):

try try
  coge_recursos;
  ...
  if cond then raise ESalida.Create;
  ...
  if cond then raise ESalida.Create;
  ...
except end;
finally 
  libera_recursos;
end;

Al ver el raise, sabemos que saltar� directamente al bloque
"except"... al menos, seguimos usando una estructura en el c�digo.