addFormException() is a method in GenericFormHandler so you can only use it from any sub-classed form-handlers. And it would not be a good idea at all to try referring your form-handler from your tax service class. Instead you can create a custom property holding the error message within your tax service component and since your tax service component most likely would be global scoped (higher than request scoped form-handler) so you can probably inject your tax service component into your form-handler so that you can get the error message from there. You can even think of a separate component also for holding error and other such things and then refer it from both components - tax service and form-handler. You may also want to have a mechanism for clearing the resetting the previous exception/error messages.
An error message property in a globally scoped component would not be thread safe. Success and error states for different shoppers would get tangled up. Unless a method signature has been designed with a place to return an error message, the usual way to report an error is to throw an exception. That can be a nuisance for a component farther up the call stack if you want to display some exception messages but not others.
The start of this thread mentioned ShippingGroupFormHandler. That form handler does not usually cause a pricing operation and therefore does not usually compute tax. If the goal is to make sure a new shipping address can be processed by the tax service, would it be possible to have the form handler (an extension of ShippingGroupFormHandler) invoke a tax service validation method directly? That method's signature could return the error message, and the form handler could call addFormException.
Thanks Clarer-Oracle for pointing the potential problem in global scoped component. I probably overlooked thread safety while replying to OP. As a best practice for global scoped component, we should make it thread safe without using locks or synchronize by setting member variables via properties file configuration as much as possible and implementing it in a way so that we can keep all thread-specific values within method variables. And in the present context it may not be possible to achieve these objectives. Better approach would be to let the exception propagate up to the form-handler, wrap it in DropletException and call addFormException().