You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
The text was updated successfully, but these errors were encountered: