feat: checkin using name

[subzero10]

Status

READY

Description

The last piece of the next iteration of Checkins. This change will allow users to use checkin names instead of ids. Closes #175.

Related PRs

• https://github.com/honeybadger-io/honeybadger-php/pull/173
• https://github.com/honeybadger-io/honeybadger-laravel/pull/111
• https://github.com/honeybadger-io/honeybadger-laravel/pull/113

Todos

• [x] Tests
• [x] Get checkin id if necessary
• [x] Documentation - https://github.com/honeybadger-io/docs/issues/346
• [x] Changelog Entry (unreleased)

[subzero10]

Hey @shalvah, I am working on the final part of this new checkins feature, which is to allow the user to checkin using the name instead of the id. For example, a checkin "A simple checkin" could be called with $honeybadger->checkin("A simple checkin"). This is the final change to allow users to configure checkin definitions entirely from the config file and not having to look for information in the dashboard.

I'm facing a small problem and I'm experimenting on what's the best way to tackle the following:

• The CheckinsClient.php class throws ServiceExceptions and does not handle them.
• The HoneybadgerClient.php class allows ServiceExceptions to be handled through a configuration parameter.
• The Honeybadger.php class uses HoneybadgerClient.php to reach the API. One of the API calls is checkin($id).
• With this PR, I want to use CheckinsClient.php (through Honeybadger.php) to call the APP (not API - that's why we're using a personal auth token) in order to get information about a project's checkins and find the id of the checkin I'm looking for.
• Here's where I'm struggling with: I want to wrap all calls to CheckinsClient.php and use the configurable handler to catch all thrown exceptions. One idea I came up with was to use add a boolean flag in the CheckinsClient.php class ($useExceptionHandler), wrap each method with a try/catch block and decide whether to throw or call the handleServiceException depending on the value of $useExceptionHandler. However, I found this to be too verbose and noisy.
• Then, I started experimenting with a Proxy class, which is the solution I currently pushed: A class with a __call magic method that wraps the call to the real class with a try catch block. But I don't know if this is good practice in the PHP world.
• If the proxy class is not a good idea, I could just duplicate the handleServiceException method from ApiClient.php in Honeybadger.php and wrap all the calls $checkinsClient with a try/catch block.

Do you have any thoughts on this? How would you go about it?

[shalvah]

Honestly...I don't know. I wouldn't say the proxy class is a bad practice, or even discouraged, especially as you're using it for an internal detail. Other alternatives would be inheritance or implementing an interface, but I think this is fine (and I think it's a form of composition), at least for the current use case. 👍 I would recommend naming it more specifically, though e.g. CheckInClientWithErrorHandling.

[subzero10]

I'll go ahead and merge, considering @shalvah's feedback above. I applied the suggested change 👌.