The specific error information is as follows:
 
webapp E com.ibm.ws.webcontainer.webapp.WebApp logError SRVE0293E: [Servlet Error]-[null]: com.ibm.ws.webcontainer.webapp.WebAppErrorReport:
at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:624)
at com.ibm.ws.webcontainer.srt.SRTServletResponse.sendError(SRTServletResponse.java:1071)
at org.apache.struts2.dispatcher.Dispatcher.sendError(Dispatcher.java:770)
at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:505)
 
Who can see the meaning of this error message?I was screwed anyway, and I couldn’t find the answer on the Internet.
 
Now that I know why, let me summarize:
First, a key piece of information is WebApp, indicating that it is an error on the application side itself
Second, the error was not clearly reported, and debugging on websphere was very inconvenient (and time-consuming), and the error was located on the row by printing the log.
(Strangely enough, that line was reported incorrectly, but why wasn’t it caught by the outer try-catch?”And that line looks fine!)
 
How did the Throwable receive a Throwable?M: How did the Throwable receive a Throwable?How did the Throwable receive a Throwable?
That’s right, it turned out to be a Throwable type error because I changed the interface class instead of updating the class file, resulting in a Throwable type error!
 
This is a real bummer… Summary of experience:
1, Some places use Throwable to catch an error. (Depending on the case, is the interface referenced but can’t find the implementation class?)
2, log records should be comprehensive, easy to locate the problem. To avoid having to change the code every time, you can set up a more comprehensive log beforehand, turn it off when you go online, and turn it on when you debug (the switch is placed in the database).