Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Voltron's EntityConfigurationException is too noisy #208

Open
ChrisGreenaway opened this issue Mar 16, 2017 · 1 comment
Open

Voltron's EntityConfigurationException is too noisy #208

ChrisGreenaway opened this issue Mar 16, 2017 · 1 comment

Comments

@ChrisGreenaway
Copy link
Contributor

ChrisGreenaway commented Mar 16, 2017

When I throw an exception on the server-side to indicate that a configuration is bad, I have to catch that exception and transform it into a ConfigurationException to meet the Voltron API. That then causes an EntityConfigurationException to be thrown on the client-side. I would expect that the EntityConfigurationException has a message that closely corresponds to the message of the exception on the server-side or that at least the cause of the EntityConfigurationException does. However, there are several layers of extra exceptions that are added.

For example, catching an exception that my code produces (a StorageFactoryException), I create a ConfigurationException with the same message and the StorageFactoryException as a cause. The message is:

"Unknown offheap resource: unknown-offheap-resource-name"

On the client-side, I receive an EntityConfigurationException with a message of:

"Entity: com.terracottatech.store.client.VoltronDatasetEntity:Dataset-address lifecycle exception: Entity: com.terracottatech.store.client.VoltronDatasetEntity:Dataset-address lifecycle exception: Entity: com.terracottatech.store.client.VoltronDatasetEntity:Dataset-address lifecycle exception: org.terracotta.entity.ConfigurationException: Unknown offheap resource: unknown-offheap-resource-name".

And the stack of causes in the EntityConfigurationException was as follows:

EntityConfigurationException
  -> EntityConfigurationException
    -> EntityConfigurationException
      -> ServerSideExceptionWrapper (representing the ConfigurationException)
        -> ServerSideExceptionWrapper (representing the StorageFactoryException exception)

So, to get my original message, I have to call e.getCause().getCause().getCause().getMessage(). This is too nested. Additionally, the message that I get has an extra prefix of "org.terracotta.entity.ConfigurationException: " which I do not want.

I should be able to get the original message of my exception by calling something well defined such as getMessage() or getCause().getMessage(). Note that I had ensured that the ConfigurationException that I threw had the message as I wanted it.

@jd0-sag
Copy link
Contributor

jd0-sag commented Apr 12, 2017

This should probably be in terracotta-core, since it is more of implementation issue (the API doesn't explicitly define how to reach through these exceptions).

In general, we need to decide how this unwrapping should work. One possibility would be to not wrap the lower-level exception, at every point, but wrap the cause (so there is only ever one level of wrapping). The potential problem is that this would drop all the internal stack frames. That might be desired, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants