Recientemente, un niño se encontró con una pregunta de entrevista: ¿Puede introducir el mecanismo de manejo de excepciones en su proyecto?
Tan pronto como el niño lo escuchó, respondió intentar-atrapar-finalmente, además de tirar y tirar.
Eso suena como una buena respuesta a primera vista. Pero eso no es lo que el entrevistador realmente quiere escuchar.
Algunos niños simplemente dijeron, ¿no es este el mecanismo de manejo de excepciones? Si crees que sí, entonces estás equivocado, por qué, déjame explicarte en detalle.
La pregunta de la entrevista en sí misma indaga sobre el mecanismo de manejo de excepciones en el proyecto, y la clave está en la palabra proyecto. El manejo de excepciones en el proyecto es mucho más que eso, todavía hay muchas cosas por hacer.
Si el entrevistador le pregunta, hábleme sobre el manejo de excepciones en Java. ¿Está bien responder try-catch-finally, además de throw and throws?
Entonces solo puedo decir que usted está como mucho calificado para ser carne de cañón para llenar el número de entrevistados. Porque es muy básico.
Entonces, ¿cómo debería responder el mecanismo de manejo de excepciones en el proyecto? Primero hablemos de por qué hay un mecanismo de manejo de excepciones.
Creo que los programadores no estarán familiarizados con las siguientes dos imágenes:
Pero si esta información anormal se muestra en la interfaz de un usuario común, ¿puede imaginar cuáles serán las consecuencias y qué le sucederá al corazón del usuario?
Mi exlíder me dijo que nunca permitiera que los usuarios vieran la información anormal del programa, porque haría que los usuarios sintieran pánico, por lo que se debe desechar la información anormal.
En el programa, si desea deshacerse de toda la información de excepción y nunca dejar que el usuario la vea, en realidad no es demasiado difícil. Solo necesita poner todo el código en el try-catch, y luego el bloque catch no hace nada. Está bien.
¿Quién dijo que funcionaría?
Déjame decirte, realmente vi a un maestro que hizo esto. Fue alrededor de 2004. En ese momento, lo que estábamos haciendo era un programa de Windows escrito en VB. Si el software en ese momento informaba un error, el programa fallaba. Simplemente cuelga. Hoy en día, muchos programas ocasionalmente fallan repentinamente. En ese momento, si el programa falla, primero aparecerán muchos mensajes de excepción en inglés y luego cerrarán el programa. Es posible que el usuario haya hecho la mitad del proceso. programa Los datos en vivo se pierden y se deben volver a hacer, de lo contrario, el programador será regañado hasta la muerte.
Pero este hombre, la "calidad" del código escrito por él es realmente buena, y nunca fallará. Más tarde, me hice cargo de su trabajo para corregir el error. El problema en ese momento era que no sabía la razón. "A veces" el programa hacía clic o no.Reacción. Encontrar la situación "a veces" en la que el programa falla es el peor bloqueo, porque no estás seguro de lo que saldrá mal. En ese momento, me volví loco cuando vi el código. Todo el código está en el bloque de prueba. Si hay un error en el procesamiento del programa, captura directamente, no se procesa nada en el bloque catch, no hay registro y no hay aviso. Nadie sabe qué error ocurrió en el programa. Si desea saber por qué el error Ocurrió, solo puede encontrar una manera de restaurar la escena del error, y debe usar herramientas de programación para depurar el código para conocer el mensaje de error.
Debe saber que los mensajes de error son muy importantes para que los programadores encuentren errores. Hacer esto hace felices a los usuarios, pero es una locura para los programadores. En ese momento, al ver esta situación, no tuve más remedio que ir al sitio, así que viajé 400 kilómetros hasta el sitio del cliente y pasé un día con el cliente en el programa antes de encontrar la causa del error y cambiar. el código en 3 minutos. Por esta razón, la empresa pagó 1000 yuanes adicionales en costos de viaje, solo para resolver un BUG que se solucionó en 3 minutos, y si había información anormal o registros de errores en ese momento, no había necesidad de hacer este viaje en todo.
¿Ahora sabe por qué es importante el manejo de excepciones en su proyecto? Y los entrevistadores experimentados también pueden ver qué tipo de hábitos de trabajo ha desarrollado en su trabajo anterior a partir del método de manejo de excepciones en su proyecto y cómo resolver problemas, y también pueden comprender los problemas en su trabajo anterior desde un lado. .
Entonces, como programador, ¿cómo responder a esta pregunta para que el entrevistador la favorezca más?
No se preocupe, primero hablemos sobre qué problemas deben considerarse en el mecanismo de manejo de excepciones en el proyecto.
Primero: se debe considerar la facilidad de uso y no debe aparecer una gran área de información anormal en la interfaz de usuario, lo que hace que los usuarios sientan pánico.
Segundo: Es conveniente recopilar información de errores y registros de excepciones.
Tercero: ¿Necesita procesar los datos de trabajo si ocurre una excepción?
Cuarto: otros problemas de lógica empresarial
En cuanto a los cuatro puntos anteriores, para los programadores que no les gusta el volumen, está bien considerar los primeros dos puntos.Para los programadores que tienen más volumen, deben prepararse más. A continuación, vamos a enhebrar uno por uno.
Primero mire el primer punto. La mayoría de los sistemas actuales son proyectos WEB. Para las solicitudes de página, la forma más fácil es usar páginas de error personalizadas. Para contenido específico, simplemente busque las páginas de error personalizadas de Tomcat.
Pero ahora muchos proyectos están separados de la parte delantera y trasera. Las solicitudes de página a las que acceden los usuarios generalmente no son procesadas por Java. Java generalmente maneja la interfaz de fondo. En este caso, es más complicado, y tanto la parte delantera como la trasera final necesita ser procesado.
El primero es el problema del backend. En general, el backend de un proyecto con front end y back end separados necesita encapsular el formato de datos devuelto. Por ejemplo, cuando necesita devolver un objeto de usuario, puede devolver directamente el siguiente Json datos:
{
userName:'Tom',userId:1,gender:'male'}
En el proyecto, generalmente se devuelven datos Json como este:
{
data:{
userName:'Tom',userId:1,gender:'male'}//前端真正需要的业务数据
code:200,//项目封装的请求状态码，具体的代码表示的含义可以自己定义
errorMessage:''//出现错误的时候返回的错误信息，可以用来提示给用户，往往是比较友好的提示信息
}
¿Cómo lograr esto? Puede buscar la encapsulación del valor de retorno de Java, y hay muchos artículos que puede consultar.
¿Qué pasa con el manejo de excepciones de back-end? La manera simple es usar una clase de manejo de excepciones globales para resolver este problema. ¿Cómo implementarlo? Puede buscar la clase de manejo de excepciones globales de Java. Esto resuelve el problema de que cada vez que ocurre un error en el proyecto, el manejo de excepciones globales El procesamiento unificado de clase permite que los datos devueltos al front-end se procesen de manera humana, y ya no devuelve una gran cantidad de pilas de llamadas de Java, lo que hace que los usuarios tengan miedo de un vistazo.
Además, en circunstancias normales, si se informa un error, se devolverá el código de estado HTTP 500. Después del manejo global de excepciones, se puede devolver a 200. El código de error específico se coloca en el código del ejemplo anterior y el front-end lo maneja de manera unificada.
Hablemos de cómo lidiar con el front-end. La pila de tecnología front-end actual usa Vue, React y Layui. No importa qué tecnología front-end se use, siempre que esté separada de la parte delantera y trasera, si la interfaz de back-end es incorrecta, también se necesita en el código de front-end Realice el manejo de excepciones, pero sería demasiado problemático manejarlo cada vez que se llama a la interfaz. Por lo tanto, el front-end también puede manejar excepciones globales.Si hay un error en la interfaz del back-end, el front-end puede mostrar un mensaje de error unificado. De esta manera, solo se necesita procesar el código comercial normal en el código comercial, y la eficiencia del desarrollo mejorará en gran medida.
El hermano programador dijo, estamos comprometidos con el desarrollo de back-end de Java, ¿necesitamos el front-end? Dije que sí, si quieres ser un programador novato, no tienes que hacerlo, pero si quieres ganar más dinero, realmente tienes que hacerlo. Un excelente programador de back-end también debe ser capaz de hacer el front-end, no tienes que ser un experto o saber los detalles, al menos tienes que saber la idea.
Hablemos del segundo punto: recopilar información de errores y registros de excepciones
Esta es una forma más sencilla y la información de la excepción se puede registrar en el manejo global de excepciones. Simplemente guárdelo en un archivo de registro de excepción fijo. Si hay un error, simplemente vaya al servidor para verificar el registro de excepción.
Por supuesto, los estudiantes que son un poco más reticentes pueden pensar en la siguiente pregunta: el registro de errores en el servidor no debería ser revisado por todos. Si el programador no tiene derecho a revisar el registro, ¿no sería muy ¿molesto? entonces que debemos hacer?
Si desea considerar los factores para que los programadores verifiquen el registro de errores, entonces puede considerar guardar la información de excepción en un sistema independiente.Si ocurre un error, el programador puede iniciar sesión en este sistema para ver la información del error.La solución específica es uno típico Es ELK, y puede BAIDU el contenido específico por sí mismo.
Además de registrar información de excepción, a veces tenemos que considerar más, como el error NPE más común, que es muy complicado de solucionar, porque la pila de llamadas solo muestra qué línea de código tiene el error y no mostrará qué objeto es. null En la última versión de las nuevas características de JDK, parece que la información de excepción puede provocar esto, pero la versión anterior aún no funciona. Si queremos averiguarlo, es posible que necesitemos registrar cuáles son los datos solicitados en muchos casos, por lo que además de la información anormal y la pila de llamadas, para facilitar la resolución de problemas, también podemos registrar los datos solicitados e incluso la información del usuario y guardar Cuanto más completa sea la información, más fácil será comprobarla.
Hablemos del tercer punto, si es necesario procesar una excepción para los datos de trabajo.
¿Qué significa eso? Para dar un ejemplo simple, algunos servicios solicitados requieren procesamiento de transacciones. Para proyectos generales, el uso normal de transacciones es suficiente. Para los estudiantes que desean obtener docenas de OFERTA K para comparar, solo responda estas Es relativamente común. Si su proyecto puede usar transacciones distribuidas, el procesamiento de transacciones distribuidas será un poco más complicado. Si hace clic aquí, es muy probable que lleve el interés del entrevistador a transacciones distribuidas.
Continúe con el cuarto punto, ¿hay alguna otra lógica comercial que deba procesarse?
Para una sola aplicación, la mayoría de los problemas de una transacción en una situación anormal se resuelven, pero para la colaboración entre múltiples sistemas, es más problemático, como el escenario de pago más típico, que involucra la relación entre su propio proyecto y el plataforma de pago Por ejemplo, en el enlace de pago, se ha llamado a la plataforma de pago y luego se informa una excepción, no sabe el resultado del pago. Por lo tanto, en este momento, no se puede garantizar que cancelar la transacción o enviarla sea 100 % correcto. La plataforma de pago generalmente proporciona un mecanismo de conciliación, es decir, si hay una excepción, la plataforma de pago le proporcionará una interfaz para que verifique si una determinada solicitud de pago se realizó correctamente, y algunas plataformas brindan conciliación una vez al día.
Para este tipo de manejo de excepciones, debe organizar un programa especial para el procesamiento de seguimiento de negocios especiales y debe analizarlo en detalle.
Hoy solo hablé sobre el mecanismo de manejo de excepciones, que es una pregunta de entrevista que responde a la pregunta de pensar. El contenido específico no es demasiado pequeño y aún necesita verificar alguna otra información. Además de estos contenidos, también hay una parte del contenido que se puede discutir, que trata sobre la cadena de herencia de excepciones en el mecanismo de manejo de excepciones de Java y el uso de clases de excepción personalizadas en proyectos De hecho, es raro preguntar este nivel en las entrevistas. , así que no hablemos de eventos de baja probabilidad, y abriré un artículo aparte para hablar de ellos cuando tenga la oportunidad.
Hablando de esto, el manejo de excepciones común en el proyecto puede cubrir básicamente el 90%. Como dije antes, si quieres ser un programador más sofisticado, necesitas saber más. Si no quieres estar tan cansado, debes debería al menos Si puede entender los dos primeros puntos, entonces también puede ganar muchos puntos para esta pregunta.
Finalmente, espero que todos puedan encontrar un trabajo satisfactorio.
Palabras clave del programador rey del volumen de hoy:
JDK14 nueva característica NPE
ELK
página de error personalizada
Transacción distribuida