Here's where I'm at: 

This chunk of code is about registering a data exporter.

If something goes wrong in registering a data exporter, best case scenario is to log it clearly and emphatically but then proceed with the portal subsystems that are working properly.  

I don't see it so much as just swallowing an exception as containing a failure to the failing component, logging it, and allowing non-failing components to proceed.

It would be better (at lot better?) if the export UI and tooling were also aware of the failure and reflected it right where an administrator needs to know, as in, in the export portlet UI and on the command line export tooling.  That would require a bit richer domain model (ability to model what the components were supposed to be and their health), and certainly seems going too far for uPortal 4.1.

So, returning to

> Is this code change just masking the underlying cause of the problem?

It's a fair concern since this is a bit whack-a-mole introducing error handling in response to a problem in the field, but no, I don't think this is just masking an underlying cause of a problem so much as it is having attention drawn to what error handling this code ought to have.  I think this is the right error handling to have for registering data exporters, in principle, regardless of the in-the-field experience that in practice this code can fail.  This is the right `try...catch` to introduce to handle failures that might in the future be introduced too.  When a data exporter fails to register it should, well, fail to register. :)