¿Cual es la diferencia? – CloudSavvy IT

Tecnología junio 8, 2021
Símbolo de peligro de falla
Shutterstock / SkillUp

Problemas informáticos. Todos los tenemos tarde o temprano. Conocer los pormenores de los errores, afirmaciones, fallas y más es vital para comprender más sobre el problema en cuestión. Aprenda todo al respecto.

Que es un Afirmar?

Cuando un desarrollador comienza a escribir código, pronto presentará if declaraciones en el mismo. Un if La declaración se utiliza siempre que es necesario probar una determinada condición. Por ejemplo, uno podría escribir un pseudocódigo if declaración de la siguiente manera:

if (water_level > high_water_mark) then {
  raise_alert
}

En otras palabras, si el nivel del agua supera la marca alta, se genera una alerta. Pero tal vez el sensor de agua esté roto, así que actualizamos el código para que coincida:

if (sensor_readout == nonsensical) then {
  raise_error
  fail
}else{
  if (water_level > high_water_mark) then {
    raise_alert
  }
}

Genial, ahora obtendremos un error y fallaremos la rutina si el sensor_readout no tiene sentido. Y solo si el valor demuestra ser sensato (debido a la else cláusula, es decir, qué hacer en la situación opuesta), proceda a comprobar el nivel_agua con la marca_alta_agua.

Sin embargo, tal vez alguien haya apagado el sensor. Podemos seguir así por un tiempo. Podemos cubrir todos los escenarios posibles imaginables y aún perder algunos. Claro, podríamos cubrir todas las situaciones posibles con una combinación else cláusula y verifique que cada condición se compare con otra, pero incluso en tales casos, podríamos haber pasado por alto algunas combinaciones de variables.

Incluso si solo tuviéramos un conjunto limitado de variables con las que trabajar, la cantidad de combinaciones posibles en las que se puede encontrar un paquete de software es bastante numerosa. Y lo que es más, este tipo de if Las pruebas condicionales ocurren con bastante regularidad en casi todo el software.

Razonando un poco más sobre este dilema, comprendemos rápidamente que nosotros (como desarrolladores) podríamos (como todos los humanos cometemos errores) tarde o temprano introducir código que permita que el software se ejecute en territorio indefinido. La variable x se establece en un valor específico, la variable y se asigna a otro, y no había ninguna disposición para esto en el código.

Ésta es precisamente la situación que una afirmación puede, hasta cierto punto, proporcionar. Una afirmación es otra condición (piénselo como otra if declaración.) que afirma si existe una determinada situación extraña / poco común / no planificada / imprevista y generalmente maneja tal situación deteniendo el programa en lugar de continuar ejecutándose con un estado indefinido / desconocido.

Si bien la red que arrojará la prueba de activos todavía se limita a la inteligencia y las habilidades del desarrollador que implementa la aserción, una aserción a menudo se puede hacer más amplia que los límites limitados de if declaraciones que prueban el estado de varias variables, o podría hacerse bastante específico para evitar ciertas situaciones peligrosas.

Por ejemplo, digamos que nuestro pequeño sensor de agua está montado en un tanque de lluvia. Por lo tanto, el agua nunca debe estar hirviendo. Sin embargo, si nuestro sensor de agua tuviera un medidor de temperatura, podríamos asegurarnos, aunque nunca sucedería / nunca debería suceder. Agreguemos una afirmación al pseudocódigo que comenzamos arriba.

En lugar del punto de ebullición (100 grados Celsius), buscaremos un máximo más razonable de 70 grados Celsius, que aún no debería alcanzarse nunca al pensar en captar agua de lluvia, al menos, en nuestra opinión. Recuerde la palabra “opinión”, ya que se vuelve importante cuando se considera la inteligencia del desarrollador que implementa la afirmación. (Más sobre esto a continuación).

if (sensor_readout == nonsensical) then {
  raise_error
  fail
}else{
  assert (water_temp < 70.0){ 
    raise_assert_message 
    fail 
    exit 
  } 
  if (water_level > high_water_mark) then {
    raise_alert
  }
}

Escribimos la afirmación al revés. El código debe afirmar que la temperatura del agua es inferior a 70 grados centígrados. Si no es así, ejecutará el bloque de código, que generará un mensaje de aserción, y luego el software fallará y se cerrará.

Las afirmaciones en el código real son bastante similares al ejemplo anterior. Comprueban si una situación determinada se aplica o no y, posteriormente, detienen (o bloquean de forma controlada) el programa / software en cuestión.

A menudo, estos activos se registran en los archivos de registro de la aplicación o incluso directamente en la salida de la pantalla. Revisarlos y / o buscar una copia del mensaje de afirmación exacto en su motor de búsqueda favorito a menudo (si el error se encontró anteriormente) lo llevará a un informe de error sobre el mismo.

Los mensajes de afirmación son a menudo errores, aunque pueden ser simplemente errores en el razonamiento del desarrollador. Después de todo, ¿quién dice que dentro de 1000 años, la lluvia podría no superar los 70 grados centígrados? (¡Esperemos que no!)

Un mensaje de aserción es la salida presentada por la aserción introducida por los desarrolladores en el código, es decir, la salida textual real generada por el software y como se muestra en la pantalla o en los registros. Por ejemplo, imagine que se muestra este mensaje de aserción para el programa anterior.

Assert: (water_temp < 70): (88 < 70): false

Aunque parece un poco críptico (como lo son algunos mensajes de afirmación), mirar un poco más de cerca nos hace darnos cuenta de que en la segunda parte, water_temp fue intercambiado por 88 y que la salida es false (es decir, la aserción water_temp <70 falló porque el agua estaba a 88 grados y, por lo tanto, la aserción desencadenó el mensaje de aserción). Sí, puede resultar un poco confuso.

Armado con estas nuevas habilidades, depurar un mensaje de aserción la próxima vez que vea uno se vuelve mucho más fácil. También es posible que le resulte más fácil comprender exactamente qué estaba fallando en el momento en que se detuvo la aplicación.

Que es un Error?

Los errores en la computación ocurren todo el tiempo y por una amplia variedad de razones. Ocurren tanto a nivel de desarrollador como de usuario y en cada paso intermedio. Por ejemplo, un ingeniero de DevOps podría olvidarse de incluir un archivo necesario, o el firmante de un paquete podría usar la clave incorrecta para firmar el software, y así sucesivamente.

En resumen, un error de ordenador se puede definir como un problema con el hardware o software de el ordenador. Hay algunos ejemplos de un error incluso en el pseudocódigo limitado anterior. Cuando el sensor_readout == nonsensical se cumple la condición, se muestra un mensaje de error.

Hay ciertos errores que son más comunes que otros. Por ejemplo, usar una ruta o un nombre de archivo incorrectos es un error común. Los problemas relacionados con la energía (por ejemplo, batería baja) también son errores bastante comunes.

Los errores son bastante separados y diferentes de los mensajes de aserción, aunque el mensaje de aserción en sí mismo puede verse como un error, o más bien, como una situación indefinida que ahora cubre la aserción. En general, un error de ordenador se traduce bastante bien en “Necesito un humano para solucionar este problema”.

A medida que las ordenadores se vuelven más inteligentes y la IA evoluciona, es de esperar que se produzcan menos errores, aunque queda mucho espacio para la discusión e incluso para los argumentos en esa área.

Que es un Choque?

Una falla de ordenador puede tomar muchas formas. Todos estamos familiarizados con las pantallas azules de Microsoft Windows, que solían ocurrir cuando una aplicación se comportaba mal o alguna parte central del sistema operativo o el hardware de la máquina fallaba.

Sin embargo, la mayoría de las veces, un bloqueo es una aplicación de software que se encuentra en una situación indefinida. Hay muchos escenarios posibles indefinidos de este tipo. Es posible que un ordenador haya intentado escribir en un área de RAM que ya estaba en uso, lo que se trastornó a sí misma oa otra aplicación, o tal vez se encontró con un escenario en el que trató de dividir por cero (lo cual es imposible), o alguna situación similar.

Muchos sistemas operativos escribirán un archivo de volcado del núcleo (si así se configura), lo que permite a un desarrollador y, a veces, a un usuario final con alguna habilidad, depurar el problema en cuestión.

Si deseas obtener más información sobre la depuración cuando las cosas van mal, incluido el análisis de los archivos de volcado del núcleo, es probable que le interese nuestro artículo Depuración con GDB: Introducción.

Un bloqueo también puede ser el resultado de una aplicación que se encuentra en una situación indefinida, que no se maneja mediante un error (la forma más sencilla para que una aplicación le informe que algo anda mal) o una afirmación (un problema más profundo, originalmente excluido por el desarrollador como imposible pero aún ocurre).

Además, tenga en cuenta que una compilación de programa para pruebas, es decir, con información de depuración (incluidas las afirmaciones de nivel de depuración únicamente) incrustadas en el binario de resultado final, puede fallar cuando produce una afirmación, como es el caso, por ejemplo, con MySQL. servidor.

Terminando

En este artículo, exploramos los conceptos de afirmaciones, errores y bloqueos, así como cómo se relacionan. Analizamos en profundidad cómo se verían las afirmaciones dentro del código y cómo esto se relaciona con un ejemplo de la vida real de monitorear el nivel y la temperatura del agua con un sensor de agua. La próxima vez que te encuentres con un mensaje de afirmación, échale un vistazo más de cerca y disfruta de la depuración.