Java 예외 처리 설계(3)
10057 단어 java 이상 처리
예외 로그 처리의 예:
이상한 점은 다음과 같습니다.
try{
... ...//N행 생략
}catch( Exception e){
throw new Runtime Exception("jar 파일 로드 이상!name="+jarFileName,e);
}
인쇄 예외는 다음과 같습니다.
logger.error(e, "클래스 파일 로드 실패");
이것은 매우 정상적인 수법으로 창고 정보를 출력하고 추가 정보를 추가한다.
처음에 예외 스택 정보는 다음과 같습니다.
(창고 정보가 좀 많아서 다들 빨리 아래를 보세요...)
java.lang.RuntimeException: jar ！D:\opt\app\WebSphere\output\report\file\loadclass\ .jar
at com.proj.report.common.util.ClassLoaderUtils.loadJar(ClassLoaderUtils.java:123)
at com.proj.report.backmanage.addin.control.ClassLoadController.loadClass(ClassLoadController.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.zollty.framework.mvc.support.HandlerMetaInfo.invokeMethod(HandlerMetaInfo.java:34)
at org.zollty.framework.mvc.handler.support.ControllerHandler.invoke(ControllerHandler.java:60)
at org.zollty.framework.mvc.handler.support.HandlerChainImpl.doNext(HandlerChainImpl.java:50)
at com.proj.report.backmanage.interceptor.AccessRightInterceptor.dispose(AccessRightInterceptor.java:62)
at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.zollty.framework.mvc.support.HandlerMetaInfo.invokeMethod(HandlerMetaInfo.java:34)
at org.zollty.framework.mvc.handler.support.InterceptorHandler.invoke(InterceptorHandler.java:58)
at org.zollty.framework.mvc.handler.support.HandlerChainImpl.doNext(HandlerChainImpl.java:50)
at com.proj.report.backmanage.interceptor.AdminRightInterceptor.dispose(AdminRightInterceptor.java:56)
at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.zollty.framework.mvc.support.HandlerMetaInfo.invokeMethod(HandlerMetaInfo.java:34)
at org.zollty.framework.mvc.handler.support.InterceptorHandler.invoke(InterceptorHandler.java:58)
at org.zollty.framework.mvc.handler.support.HandlerChainImpl.doNext(HandlerChainImpl.java:50)
at org.zollty.framework.mvc.servlet.DispatcherController.handleRequest(DispatcherController.java:52)
at org.zollty.framework.mvc.DispatcherServlet.dispatcher(DispatcherServlet.java:69)
at org.zollty.framework.mvc.DispatcherServlet.doPost(DispatcherServlet.java:33)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:133)
at java.util.jar.JarFile.(JarFile.java:70)
at com.proj.report.common.util.ClassLoaderUtils.loadJar(ClassLoaderUtils.java:120)
... 39 more
이것은 매우 간단한 오류 보고이지만, 창고는 오히려 무더기로 쌓여 있어 사람을 막연하게 한다.사실, 내가 말하고 싶은 것은 이 창고 정보는 비교적 적은 편이다. 웹 sphere에서 오류 보고가 더 많고, 우리의 오류 로그 파일은 보통 1분 몇 M, 심지어 몇 십 M이다. 내가 다운로드한 로그 파일은 800여 M이다.
내가 많은 로그 파일에 대한 분석을 통해 그 중 90퍼센트의 오류 보고가 불필요한 것임을 발견하였다.
예외적인 처리를 통해 오류 로그는 다음과 같이 변경되었습니다.
16:07:59415 ERROR ClassLoadController:29 - 클래스 파일 로드 실패 | java.lang.RuntimeException:jar 파일 로드 예외!D:\opt\app\WebSphere\output\report\file\loadclass\사진.jar
at com.proj.report.common.util.ClassLoaderUtils.loadJar(ClassLoaderUtils.java:123)
at com.proj.report.backmanage.addin.control.ClassLoadController.loadClass(ClassLoadController.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
... 6 more
at com.proj.report.backmanage.interceptor.AccessRightInterceptor.dispose(AccessRightInterceptor.java:62)
... 6 more
at com.proj.report.backmanage.interceptor.AdminRightInterceptor.dispose(AdminRightInterceptor.java:56)
... 23 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:133)
... 1 more
at com.proj.report.common.util.ClassLoaderUtils.loadJar(ClassLoaderUtils.java:120)
... 39 more
위의 오류 로그가 많이 없어졌는데, 일부는'...6 more','...23 more'로 대체되었습니다.
이렇게 간소화한 후에 오류에 대한 포지셔닝이 훨씬 뚜렷해졌다.
예를 들어, 위의 로그를 분석합니다.
1) 먼저 오류 메시지를 읽습니다.
클래스 파일 로드 실패 | - java.lang.RuntimeException:jar 파일 로드 예외!D:\opt\app\WebSphere\output\report\file\loadclass\사진.jar
오류의 개황을 알고 있습니다. "클래스 파일 불러오는 데 실패했습니다."
2) 오류 정보에 따라 다음 세 줄의 오류가 지나가는 클래스 경로를 똑바로 보십시오.
com.proj.report.common.util.ClassLoaderUtils.loadJar(ClassLoaderUtils.java:123)
at com.proj.report.backmanage.addin.control.ClassLoadController.loadClass(ClassLoadController.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
이 세 줄의 데이터에서 나는 이 이상 정보가 ClassLoader Utils에서 나왔다는 것을 알았다.loadJar (ClassLoader Utils.java:123) 이 곳은 new에 의해 나왔다.여기에는 throw new Runtime Exception () 이라는 문구가 있습니다.또 아래에 Caused by:java가 있습니다.util.zip.ZipException 문장, 그래서 진정한 작법은 throw new Runtime Exception (e), 그 중에서 이 e의 유형은java라고 단정합니다.util.zip.ZipException.
그 후의 데이터는 프로그램이 호출한 궤적이다. 아마도 Http를 통해 차단기와 Servlet에 들어갔고 액션(Controller)에 이르렀을 것이다. 나는 핵심적인 궤적 정보만 기록했다.일반적으로 이런 궤적 정보는 쓸모가 없다.너는 심지어 전부 제거할 수도 있다.프로젝트 패키지 이름 "com.proj.report.*"로 시작하는 정보만 유지하면 됩니다.
Caused by 문구를 다시 보면 이것이야말로 잘못된 진정한 원시 출처이다.
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
즉, 가장 밑바닥, 가장 원천적인 오류는 ZipFile에서 나온 것이다.open(Native Method)에서 new가 나왔습니다.오류 정보: error in opening zip file
이어서 뒤를 쳐다보니 마지막이 보였다.
com.proj.report.common.util.ClassLoaderUtils.loadJar(ClassLoaderUtils.java:120)
... 39 more
이것은 우리가 쓴 프로그램에서 오류의 가장 원천은
ClassLoaderUtils.loadJar(ClassLoaderUtils.java:120)
이 공구류의 120줄에서 던져진 것이다.
그렇다면 온전한 잘못된 궤적, 잘못된 원인과 잘못된 출처를 우리는 모두 잘 알고 있다.그리고 상기 정보에 근거하여 나는 프로그램이 호출하는 궤적을 분석할 수 있다. (일반적으로 말하자면, 필요없고, 쓸모가 크지 않다)
상부 프로그램의 층층이 호출을 거쳐 도착했다.
ClassLoadController.loadClass(xx)
그리고 호출:
ClassLoaderUtils.loadJar(xx)
이 방법에서 다음과 같은 점이 있습니다.
ClassLoaderUtils.loadJar(ClassLoaderUtils.java:120)
120줄로 오류가 발생했습니다.
이것이 바로 핵심적인 프로그램 운행 궤적이다. loadClass 위의 궤적과loadJar 이후의 궤적은 다른 API의 운행 궤적으로 우리가 통제할 수 없는 범위에 속하기 때문에 인쇄하는 의미가 크지 않다.물론, 내가 쓴 이 이상 처리 도구는 설정할 수 있다. 예를 들어 SpringAPI의 운행 궤적을 보고 싶다면, 패키지 이름, 예를 들어 org를 배제하지 않아도 된다.springframework.mvc.
이 정도로는 부족합니다. 더 강력한 도구를 썼습니다. Exception Wrapper, Throwable의 방법을 다시 썼습니다.밑바닥에서 이상 정보를 개조하다.솔직히 썬 JDK 안에 있는 그 Throwable는 디자인이 좋지 않아요. 그 전에 IBM JDK에서 테스트를 했는데 문제를 발견하지 못해서 썬 JDK로 바꾸면 문제가 생겼어요.상세한 내용은 내가 쓴 문장 소개를 보십시오.
http://www.cnblogs.com/zollty/p/3396252.html
Open JDK와 GUN JDK는 모두 개선된 것이다.제가 쓴 이 Exception Wrapper는 JDK가 가지고 있는 Runtime Exception을 대체해서 사용할 수 있습니다.더욱 강력한 기능앞으로 나는 전문적으로 문장을 써서 이 도구를 소개할 것이다.
ExceptionWrapper로 포장된 최종 오류 스택 정보는 다음과 같습니다.
클래스 파일 불러오기 실패 | -jar 파일 불러오기 이상!D:\opt\was\file\loadclass\사진.jar
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:133)
... 1 more
at com.proj.report.common.util.ClassLoaderUtils.loadJar(ClassLoaderUtils.java:122)
at com.proj.report.backmanage.addin.control.ClassLoadController.loadClass(ClassLoadController.java:41)
... 7 more
at com.proj.report.backmanage.interceptor.AccessRightInterceptor.dispose(AccessRightInterceptor.java:62)
... 7 more
at com.proj.report.backmanage.interceptor.AdminRightInterceptor.dispose(AdminRightInterceptor.java:56)
이렇게 해서 나는 만족했다.위의 창고 정보에서 나는 오류의 원인과 오류를 보고하는 곳, 그리고 프로그램이 실행되는 궤적을 거의 완벽하게 볼 수 있다.
좋은 웹페이지 즐겨찾기
