Convert methods with checked exceptions to unchecked (support streaming and functional programming)

[Haarolean]

Hi,
GHObject#getCreatedAt and GHObject#getUpdatedAt throw unnecessary IOException which is not being thrown by an underlying code. Is there a reason for this?

[bitwiseman]

Most likely reason is they had code that could throw an IOException in the past and changing them now would result in API breaking changes. It is also possible that some derived classes include code that could throw IOException and this was done to support those.

[Haarolean]

@bitwiseman have you considered getting rid of all checked exceptions at all?

[bitwiseman]

@Haarolean
Not in short term. Doing so would be an API breaking change requiring us (based on semver) to create a new major version. Likely, that would involved adding a new package beside the original package to maintain backward compatibility for some period.

Also, Why would we do that? Is it particularly needed?

[Haarolean]

@bitwiseman It prevents end users from using library's calls within Java streams.

[bitwiseman]

@Haarolean
Ah, I see. Here's a discussion of workarounds. None of them seem very nice, so I can see why you'd want to avoid that.

We're not ready to introduce binary breaking changes at this time. We use "bridge methods" if needed to preserve binary compatibility but I don't think that will work here.

We could try introducing new methods called createdAt() and updatedAt() which wrap those getCreatedAt() and getUpdatedAt() method to rethrow the IOException as GHException. I'm not sure that's a great choice either, but at least it is non-breaking.

[Haarolean]

@bitwiseman
why are we refraining from breaking changes so much? All of the users are developers in the end, and bumping the library to a new major version shouldn't be a big issue considering migrating some of the things (I doubt people catch these IO exceptions and do something meaningful with them).

[bitwiseman]

@Haarolean
The removal the IOException will result in compilation failures - if not caught, then the caller must also declare throws IOException. If that caller no longer calls any other method that throw IOException, that caller will need to remove throws IOException from its signature. Then cascade that problem throughout the consuming codebase. For small self-contained projects that might not be a big deal, but it is still work. For large projects, that work can cascade to multiple components resulting in many days of work.

Also, you are assuming that all consumers of this library must compile against a new version in order to use it. Many consumers of this library, in particular Jenkins, do so via a plugin system. The exceptions thrown by a method are part of the binary method signature. This results in binary breaking changes potentially causing MethodNotFoundExceptions in two different ways - old consumer trying to call a method with the exception when the new library containing the method without the exception is loaded, or also newly compiled consumer trying to call a method without the exception when running in an environment with the old library containing the method with the exception is loaded.

The level of firestorm that has occurred in the past in the Jenkins project when this project accidentally made binary breaking changes is impressive. It wouldn't happen now because they have added runtime tests to guard against it, but let's not go there.

To be clear, I see value in the "streaming" use case and it would be great to add better support for it. But there's a number of other features an scenarios that would provide greater value to more consumers of this library.

Introducing binary breaking changes is not an option, but there are still a number of options for introducing new APIs and functionality. They're not as easy or quick, but so it goes.

[Haarolean]

@bitwiseman
While I agree that the other changes are way more important than changes like this one, in general, it sounds like refraining from introducing breaking changes and releasing major versions might drastically reduce the innovation. Moreover, the whole development progress might be held hostage for the sake of serving some big consumer (like Jenkins) to help them avoid adapting their codebase to properly consume new changes to the library.

[bitwiseman]

@Haarolean

the whole development progress might be held hostage for the sake of serving some big consumer (like Jenkins) to help them avoid adapting their codebase to properly consume new changes to the library.

You should definitely try helping Jenkins adapt their codebase to properly consume new changes to this library... 🤣 I wish you the best of luck. Also, Jenkins is not alone.

Here's an article on how to wrap method that throw checked exceptions to make them throw unchecked: https://www.oreilly.com/content/handling-checked-exceptions-in-java-streams/

That article mentions this library: https://github.com/vavr-io/vavr

If you'd like to start work on a v2.x of this library, I'd be happy to talk about features and direction.

[Haarolean]

@bitwiseman

It seems like you're missing my point. For instance, I can't imagine a situation when GitHub would avoid implementing new breaking changes solely because a major client is facing challenges in updating their code to support the new API.

I appreciate your suggestions for workarounds. However, my concern goes beyond this specific problem. There are other issues/PRs/changes in this library that could potentially introduce breaking changes. Unfortunately, it seems there's little to no traction toward doing so, though I believe this is off-topic for this particular issue.

[bitwiseman]

I can't imagine a situation when GitHub would avoid implementing new breaking changes solely because a major client is facing challenges in updating their code to support the new API.

I surprised that you would say that. They absolutely avoid making breaking changes, not just for major clients but for all clients. Look at any of the breaking changes they've made over the past ten years and you will see a history of planning those changes very carefully, implementing non-breaking side-by-side replacements whenever possible, communicating the breaking changes years in advance, and finally pulling the trigger on the changes.

Unfortunately, it seems there's little to no traction toward doing so

That's because there are very few contributors willing/able to devote the time needed to implementing any changes or enhancements to this library, and even fewer willing/able to devote the time needed to following a process like GitHub of side-by-side replacement and clear planning and communicating of eventual removal/breaking changes.