La programación es 50% construir – 50% arreglar. El arte de construir es algo maravilloso y lo que nos produce mayor satisfacción… Por el contrario, arreglar los errores (que nosotros mismos construimos) puede tornarse un trabajo más difícil que programar, puede hacer de tu vida un infierno, hasta el punto en que te haría dudar sobre si elegiste bien tu profesión o debiste ser veterinario (si lo sé, exagero ).

Arreglar errores es todo un tema aparte, pero… ¿Cómo poder arreglar algo que no sabemos por qué se produce, cuando se produce y dónde se produce?

Para eso se inventaron las descripciones de errores (junto con un número de identificación). Aunque algunas veces esas descripciones son tan útiles como un destornillador para zurdos. Es algo que yo llamo “errores ciegos”, errores que no dicen nada, errores que no aportan nada a la resolución y estorban o confunden.

Por ejemplo, errores como los que el WordPress da:

“Ha ocurrido un error sin identificar.” ¿que rayos ha pasado? Algunos podrían decir que “por lo menos me lo ha dicho en mi idioma”. Pero esta descripción de “sin identificar” no ayuda en nada, y simplemente deja una única opción al usuario: resignarse, y empezar a rezar para que no ocurra de nuevo.

Errores en PHP

Gracias a una función encontrada en los comentarios de la documentación de PHP, podemos conseguir que los errores mostrados digan algo más que un simple “ha ocurrido un error, jodete!” y así poder cercarlo y solucionarlo

La función en cuestión es la siguiente:

function my_error_handler($errno, $errstr, $errfile, $errline){
  $errno = $errno & error_reporting();
  if($errno == 0) return;
  if(!defined('E_STRICT'))            define('E_STRICT', 2048);
  if(!defined('E_RECOVERABLE_ERROR')) define('E_RECOVERABLE_ERROR', 4096);
  print "<pre>\n<b>";
  switch($errno){
    case E_ERROR:               print "Error";                  break;
    case E_WARNING:             print "Warning";                break;
    case E_PARSE:               print "Parse Error";            break;
    case E_NOTICE:              print "Notice";                 break;
    case E_CORE_ERROR:          print "Core Error";             break;
    case E_CORE_WARNING:        print "Core Warning";           break;
    case E_COMPILE_ERROR:       print "Compile Error";          break;
    case E_COMPILE_WARNING:     print "Compile Warning";        break;
    case E_USER_ERROR:          print "User Error";             break;
    case E_USER_WARNING:        print "User Warning";           break;
    case E_USER_NOTICE:         print "User Notice";            break;
    case E_STRICT:              print "Strict Notice";          break;
    case E_RECOVERABLE_ERROR:   print "Recoverable Error";      break;
    default:                    print "Unknown error ($errno)"; break;
  }
  print ":</b> <i>$errstr</i>\n";
  if(function_exists('debug_backtrace')){
    //print "backtrace:\n";
    $backtrace = debug_backtrace();
    array_shift($backtrace);
    foreach($backtrace as $i=>$l){
      print "[$i] in function <b>{$l['class']}{$l['type']}{$l['function']}</b>";
      if($l['file']) print " in <b>{$l['file']}</b>";
      if($l['line']) print " on line <b>{$l['line']}</b>";
      print "\n";
    }
  }
  print "\n</pre>";
  if(isset($GLOBALS['error_fatal'])){
    if($GLOBALS['error_fatal'] & $errno) die('fatal');
  }
}

function error_fatal($mask = NULL){
  if(!is_null($mask)){
      $GLOBALS['error_fatal'] = $mask;
  }elseif(!isset($GLOBALS['die_on'])){
      $GLOBALS['error_fatal'] = 0;
  }
  return $GLOBALS['error_fatal'];
}

¿Como se usa?

Muy fácil:

set_error_handler('my_error_handler');

set_error_handler se encarga de enviar todos los errores a la función my_error_handler, la cual parsea, formatea e imprime en pantalla los errores.

Veamos la diferencia:

Sin la función de errores:

Fatal error: Un extraño error ha ocurrido. No le daré más información. in C:\AppServ\www\errores\db.php on line 9

Con la función de errores:

User Error: Un extraño error ha ocurrido. No le daré más información.
[0] in function trigger_error in C:\AppServ\www\errores\db.php on line 9
[1] in function tierno_y_jugueton in C:\AppServ\www\errores\db.php on line 4
[2] in function dulce_conejito in C:\AppServ\www\errores\index.php on line 8

Los números iniciales, significan el grado de “profundidad” del error. En este ejemplo, trigger_error está dentro de la función tierno_y_jugueton, que a su vez está dentro de la función dulce_conejito, que fué llamada desde index.php en la línea 8.

Puedes descargar el ejemplo y comprobarlo tu mismo!

Realmente esto es muy útil de tener en cuenta para debuguear.

Los efectos laterales

Las modificaciones que se produzcan mediante una función o procedimiento en elementos situados fuera del subprograma se les conoce como “efectos laterales”, estos pueden ser en algunos casos beneficiosos a la hora de programar pero es conveniente NO recurrir a ellos.

En Procedimientos y funciones.

Cuando un procedimiento modifica una variable global se le llama “efecto lateral”, esto no quiere decir que no se puedan utilizar variables globales dentro de procedimientos, si no que es necesario que al llamar (al procedimiento) la variable global sea introducida en este como parámetro, todo esto aplicará igualmente para las funciones que de ninguna manera deberán manipular variables globales para no interferir con el comportamiento correcto del programa.

Constantes son la excepción

En lenguajes de alto nivel donde existen las constantes, éstas si pueden ser utilizadas directamente en el procedimiento ya que de ninguna forma podrán ser modificadas dinámicamente

¿Por qué no usar “los efectos laterales”?

Dos simples razones para NO utilizar los efectos laterales:

• Por que es perjudicial a la hora de programar
• Dificultan el mantenimiento del código.

Si alguien tiene una opinión diferente con respecto a utilizar los efectos laterales, que nos lo comente .

El día de ayer aquí en la oficina me avisaron de que una aplicación web estaba fallando, tirando el mensaje

Fatal Error: Allowed memory size of X bytes exhausted….

Causa

Esto sucede por que la app. necesita más memoria reservada para trabajar

Solución

Para solucionar este sencillo problema tenemos 3 opciones:

1. Modificar el PHP.ini
   

   Ubicamos la variable memory_limit y cambiamos su valor(por default 12M).

2. Usar ini_set para cambiar la variable de configuración del php.ini directamente desde tu script
   

   La función que usaremos en este caso sería ini_set, de la siguiente forma:
   ini_set(“memory_limit”,”xM”); (siendo x la memoria reservada para el PHP).

3. Creando un .htaccess o modificando el httpd.conf de apache.
   

   Modificando el .htacces o httpd.conf del apache y agregando la linea
   php_value memory_limit xM.

El valor que debes colocar depende de cuanta memoria reservada requiera tu script, en mi caso yo he colocado 50M y el script funciona de maravilla!

Hasta la próxima.!