Hello!

Sesion17

<h1 id="genericidad-en-java">Genericidad en Java</h1>



<h3 id="otras-reglas">Otras reglas</h3>

<p>Se puede tener una genericidad restringida multiple con varias interfaces y una unica clase <br>
No se pueden crear instancias de parámetros genéricos <br>
Tampoco crear caracteristicas estáticas de tipo T</p>

<h1 id="tema-6-programación-defensiva-y-tratamiento-de-exepciones">TEMA 6. PROGRAMACIÓN DEFENSIVA Y TRATAMIENTO DE EXEPCIONES</h1>



<h2 id="programación-defensia">Programación defensia</h2>

<blockquote>
  <p>Para obtener elementos software fiables es necesario diseñar componentes que se potejan a si mismos. <br>
  Práctica de escribir programas en un modo diseñado específicamente para facilitar el proceso de validación y debugging</p>
</blockquote>

<p>Posibles problemas</p>

<ul>
<li>Entradas no validas</li>
<li>Ficheros que no existen</li>
<li>…</li>
</ul>

<h4 id="enfoque-de-la-programación-defensiva">Enfoque de la Programación Defensiva</h4>

<ul>
<li>Es mejor comprobar demasiado que demasiado poco.</li>
<li>Siempre chequear el cumplimiento de la precondición</li>
<li>Penalización de rendimiento</li>
</ul>

<p>Cuando ocurre un error en los datos es necesario lanzar una exepción a que haya una mala ejecución</p>

<p>En el diseño por contrato se utiliza <code>assert</code> para preveer un correcto funcionamiento que permite ser eliminada la comprobación. Trata de reducir el código para evitar comprobaciones exesivas y eliminar posibles fallos nuevos.</p>



<h4 id="fallo-o-fracaso">Fallo o fracaso:</h4>

<p><em>Una llamada a una rutina tiene exito si termina su ejecución en un estado en el que satiface el contrato del método.</em></p>

<h4 id="excepción">Excepción:</h4>

<p><em>Suceso en tiempo de ejecución que puede causar que una rutina fracase.</em></p>

<p>Un fracaso != excepción</p>



<h3 id="fuentes-de-excepciones">Fuentes de excepciones</h3>

<ul>
<li>Hacer llamadas a referencias a objetos nulos</li>
<li>Asignar null a un tipo primitivo (Java desaproved)</li>
<li>Operación anormal detectada por el hardware o el sistema operativo (StackOverflow)</li>
<li>Llamar a otra turina que a su vez falla</li>
<li>Ejecutar instrucción que lanze una excepcion <em>“Como si hubiera pocas”</em></li>
<li>Aserciones (solo contrato)</li>
</ul>



<h3 id="soluciones-a-excepciones">Soluciones a excepciones</h3>



<h4 id="excepciones">Excepciones</h4>

<ul>
<li>Despreocupada: <br>
No hacemos nada</li>
<li>Burocrática <br>
Informo de las excepción y no lo arreglo</li>
<li>Salvaje <br>
Paro la ejecución del programa.</li>
</ul>

<p>La solución burócratica puede llevar consigo un continuo degradado de los datos provocando una inconsistencia de los datos.</p>



<h3 id="principios">Principios</h3>

<ul>
<li>Fracaso o pánico organizado <br>
<ul><li>Limpiamos el entorno, terminamos las llamadas e informamos de fallo. Quien hace la llamada puede a su vez reintentar o a su vez realizar un cerrado continuo de los recursos solicitados.</li></ul></li>
</ul>



<h3 id="control-de-expeciones-tratamiento">Control de expeciones - Tratamiento</h3>

<pre><code>try //Intenta realizar algo que puede generar excepciones
catch //Capturar excepción
finally //Qué hacer al finalizar
throw[s] //Lanza excepción[es]


try{
    sentencias-excepción;
}
catch(Exception1 e1){
    sentencia-recate1;
catch(...){
    ...
}finally{
    sentencias-liberación;
}
</code></pre>