Question one,
In actual use zuul found a problem when routing address can not reach, zuul throw Filter threw Exception, shielding the actual error.
By reading the source code available, Zuul ZuulException exception will be thrown, will be encapsulated within RunTimeException.
Throwable need to use interceptors capture.
Question two,
The above code derived from com.netflix.zuul.http.ZuulServletthe servicemethod of implementation that defines processing when Zuul external request process, the execution logic of each type of filter. We can see from the three code try-catchblocks, which in turn represent the pre, route, postthree stages of filter calls, in the catchexception processing, we can see that they are all errortypes of filter process (prior to use errorfilters defined uniform exception handling also took advantage of this feature); errorafter the type of filter processed, in addition from postoutside of the abnormal phase, will then be posttreated filter. For the postcase thrown exception filter in through the errorafter filter processing, no other type of filter to take over the presence of the root causes of deficiencies in the program before using it is.
Recall that two kinds of exception handling methods prior to implementation, in which the very core of it, these two treatment methods in the context of exception handling request time to add a series of error.*parameters, and these parameters where the real work is in the poststage of SendErrorFilterin the filter parameters will be used to organize the content back to the client. As for the postcase of phase throwing an exception by errornot calling after processing filter postrequest phase, of course, these error.*parameters will not be SendErrorFilterthe consumer output. So, if we have a custom postfilter when not properly handle the exception, it is still likely to appear in the log and no abnormal response to a request is empty question. We can modify before ThrowExceptionFilterthe filterTypemodification is postto verify the existence of this problem, pay attention to remove the try-catchprocessing block, it can throw an exception.
To solve the above problems there are many, such as the most direct we can achieve errorwhen the filter results are returned directly to the organization will be able to achieve the effect, but such shortcomings are obvious, for information organization and error codes returned achieve it there will be multiple copies, this is very difficult for our future code maintenance work. Therefore, in order to maintain consistent exception return processing logic, we still hope will be postan exception to be able to filter thrown SendErrorFilterto handle.
In the foregoing, we have achieved a ErrorFiltercaptured pre, route, postfilter thrown exception, and tissue error.*parameters within the context of the request. Since our goal is to follow SendErrorFilter, these error.*parameters are still useful to us, so we can continue to use the filter to make it in posttime to throw an exception filter, continue to organize error.*parameters, but here we can not have these error.*parameters before being passed to SendErrorFitlerfilter It is to deal with. So, we need to ErrorFilterre-define the filter after a errortype of filter, let it come to realize SendErrorFilterthe function, but the errorfilter does not need to deal with all the unusual circumstances, it is only postan exception was thrown effective filter. According to the above ideas, we can create a class that inherits from SendErrorFilterthe filter, it can reuse runmethod, and then rewrite it to the type, order, and execution conditions, to achieve multiplexing of the original logic, specifically implemented as follows:
https://www.cnblogs.com/duanxz/p/7543040.html
