#1452 simplify MethodsCompletionException implementation

[osigida]

MethodsCompletionException is simplified; fixes #1452

Category (place an x in each of the [ ])

• bolt (Bolt for Java)
• bolt-{sub modules} (Bolt for Java - optional modules)
• slack-api-client (Slack API Clients)
• slack-api-model (Slack API Data Models)
• slack-api-*-kotlin-extension (Kotlin Extensions for Slack API Clients)
• slack-app-backend (The primitive layer of Bolt for Java)

[WilliamBergamin]

Hi @osigida thanks for your interest and taking time to open a PR for this 💯

Unfortunately these changes would break the current interface contract established by by the library. We would consider this a breaking change and would need to include it as part of a major version.

We can include these types of improvements in our next major version but for the time being we do not have plans to release one in the near future.

I would suggest closing this PR for the time being and keeping #1452 open in order to track the feature request

[osigida]

Hi @WilliamBergamin! thanks a lot for the reply.
I can make it backward compatible — just a few methods to support previous implementation.
And backward compatibility could be removed in 2.0
Should I?

[seratch]

Let me share my thoughts as former maintainer of this project:

The underlying API client (MethodsClient) can throw any of these, and the current implementation provides getters to access them. So, it's not because of the breaking change, these data structure should not be eliminated. I hear that having three types here could be unnecessary for most cases, but this could be still beneficial for other users.

If your concern is the lack of easy-to-use getMessage() method, the internal code could be changed just to override getMessage() to return the underlying exception's message string data. Only one of these three usually exists, so checking the existence of them one by one within overridden getMessage() method should work for the purpose.

This could be a minor breaking change, so ideally it should be considered in the next major version. But in practice, having such a change with sufficient notice in release notes should be okay too.