https://issues.apache.org/bugzilla/show_bug.cgi?id=57021
--- Comment #15 from VIN <reachme.va...@gmail.com> --- (In reply to Christopher Schultz from comment #9) > (In reply to VIN from comment #8) > > Created attachment 32460 [details] > > Updated patch with suggested comments > > > > Please let me know if anything is missing. > > The doc/*.html files should not be in the patch... they are auto-generated > from the xml files elsewhere. Hi Chris, I generated the Javadoc from Eclipse which generated those many HTML files. I was not aware that we should not be putting all those files into patch. Can you help explain me on what is the best approach to generate the java doc and what files need to be uploaded in generated files? > In AprLifecycleListener near line 208, instead of catching Throwable and > then checking for LibraryNotFoundError and UnsatisfiedLinkError, why not add > catch clauses and leave the default action in catch(Throwable)? I think this > will be a better way to do things. I have gone through multiple links to understand between catching an exception vs catching Throwable and my findings are: When we catch Exception, all sub classes of exception will be caught but ERRORS will not be part of them. (ERRORS are serious problems like MemoryOutOfBound where JVM may need to shutdown). Throwable is super class of all Exceptions and Errors and when we catch Throwable all the Errors also will be caught. But from JAVA Doc: An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it. It means applications should not try to catch Throwable. I have seen many places in our Tomcat application, catching the Throwable. In this regard, can you help me to understand why do we use Throwable and where can it be used in general? > > I'm not sure what the implications are, but the old (and default case) code > adds the log message to initInfoLogMessages while the new code performs > logging directly. Is there a reason to prefer one over the other? The initInfoLogMessages holds only the INFO messages, but as per the bug request we need to log the exception as warning. Hence i did not add it to initInfoLogMessages. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
