Recently began to learn the Dubbo framework, in the work of the previous business will be transferred.
In the original Spring MVC framework implementation, there was a scenario that used a custom exception (custom exception inheritance runtimeexception). For exceptions (including custom exceptions), no try-catch operations are done in the business code, and the exception is handled by the common controller.
In the process of using Dubbo, when the service side of Dubbo is defined with a custom exception to throw, it is found that it cannot be instanceof in the customer's controller, and its own custom exception class is turned into runtime exception. A little bit out of comprehension. When looking through the Dubbo source code, found that this is true:
Public Result Invoke (invoker<?> Invoker, invocation invocation) throws Rpcexception {try {Result result = Invoker.invoke (invocation); if (Result.hasexception () && Genericservice.class! = Invoker.getinterface ()) {try { Throwable exception = Result.getexception (); If it is an checked exception, throw the IF (!) directly. (Exception instanceof RuntimeException) && (Exception instanceof exception)) {return Resul T }//There is a declaration on the method signature that directly throws a try {method = Invoker.getinterfac E (). GetMethod (Invocation.getmethodname (), invocation.getparametertypes ()); class<?>[] exceptionclassses = Method.getexceptiontypes (); for (class<?> exceptionclass:exceptionclassses) {if (Exception.getclass (). Equals (Excep Tionclass)) { return result; }}} catch (Nosuchmethodexception e) {return result; }//exception not defined on the method signature, print error log logger.error on server side ("Got Unchecked and U Ndeclared exception which called by "+ Rpccontext.getcontext (). Getremotehost () +". Service: "+ invoker.getinterface (). GetName () +", Method: "+ invocation.getmethodname () +", Exception: "+ Exception.getclass (). GetName () +": "+ exception.getmessage (), exception); The exception class and the interface class are directly thrown in the same jar package as String servicefile = Reflectutils.getcodebase (Invoker.getinterface ()); String exceptionfile = Reflectutils.getcodebase (Exception.getclass ()); if (Servicefile = = NULL | | exceptionfile = = NULL | | servicefile.equals (exceptionfile)) {return resUlt }//Is the JDK's own exception, thrown directly by String ClassName = Exception.getclass (). GetName (); if (Classname.startswith ("java.") | | classname.startswith ("javax.")) {return result; }//is an exception to the Dubbo itself, thrown directly if (exception instanceof Rpcexception) { return result; }//Otherwise, the wrapper is runtimeexception thrown to the client return new Rpcresult (New RuntimeException (Stringuti Ls.tostring (Exception)); } catch (Throwable e) {Logger.warn ("Fail to Exceptionfilter if called by" + Rpccontext.getcontext () . Getremotehost () + ". Service: "+ invoker.getinterface (). GetName () +", Method: "+ invocation.getmethodname () +", Exception: "+ E.getclass (). GetName () +": "+ e.getmessage (), E); return result; }} return result; } catch (RuntimeException e) {logger.error ("Got unchecked and undeclared exception which called by" + Rpccont Ext.getcontext (). Getremotehost () + ". Service: "+ invoker.getinterface (). GetName () +", Method: "+ invocation.getmethodname () +", exceptio N: "+ E.getclass (). GetName () +": "+ e.getmessage (), E); Throw e; } }Therefore, the service side of the Dubbo to throw a custom exception, can only be passed on the service side of the interface method to declare the exception to be thrown, or the exception class and interface to the same package, or the implementation class of the interface to implement the Dubbo Genericservice interface.
It is not used for the first scenario because it is more serious about code intrusion.
The second scenario can be implemented, and for the current business framework, it becomes less likely that interface classes and exceptions are similar to packages.
So finally chose to let the interface implementation class to implement Genericservice interface, but for its need to implement the $invoke method does not do any method body processing, directly discarded.
For Dubbo service-side custom exception class processing, some do not understand is why Dubbo need to do a runtime exception to the custom exception class conversion, rather than directly throw the original exception type. Or if you have a friend who knows more about Dubbo, there is a better way to handle a custom exception.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Dubbo throwing a custom exception