If an MBean implements MBeanRegistration and throws an exception from its postRegister method, then that exception will be propagated from the createMBean or registerMBean call that registers the MBean, wrapped in RuntimeMBeanException. This behaviour is consistent with the spec but potentially surprising. Users presumably expect that if create/registerMBean throws an exception then the registration has failed.

Changing the behaviour so that an exception from postRegister is ignored would risk compatibility problems. We don't know if people might be catching RuntimeMBeanException for some reason.

However, we could reasonably do the following. First, we could log a message at FINE level to say that postRegister threw an exception but that the MBean has been registered all the same. Second, we could a @throws RuntimeMBeanException clause to registerMBean and createMBean documenting that these methods can throw that exception if postRegister throws an exception and that the MBean is registered all the same. We might need to have @throws RuntimeErrorException too.
There can still be an issue here, which again isn't that major, but is worth noting.

If the mbean supplied its own ObjectName through implementing preRegister() then this information is lost to the client that is registering the mbean, since the ObjectInstance is no longer returned if the exception is thrown. Therefore the code that registered the mbean can no longer unregister or interact with the mbean through the mbeanserver unless there is specific provision for obtaining the ObjectName from the MBean instance's code.

Even more twistedly than a null ObjectName parameter passed in at registration, a non-null ObjectName passed in as a parameter can also suffer from this problem since preRegister can override the value that is used, and the way of this being returned is through the ObjectInstance return value from registerMBean.