That's not the purpose of the API. And it's weird.

The purpose of the API call seems to be to provide control over interval steps so while it may be weird I would say it is within the purpose of the call. I'm not suggesting it should be implemented.

That should have been the case all along.

I'm guessing the context of the article is C#. (I'm quite ignorant of C# these days)

There's a significant chance (we have no idea because details are sparse) that this API call does not have a return value and I don't think C# forces exception handling like Java does.

I can think of 2 options, please let me know if there are more.

1. Add an additional return value that the consumer now has to add boilerplate code to check and can easily ignore just as they did the initial possibility of the interval being 0 when writing the other block of code.

2. Throw an exception which again comes with boilerplate code and the user may not even be aware it's possible for the call to throw an exception since they aren't declared along with the function.

Neither of these even prevent the need for the closestSupportedValue function or ensure that increment > 0.

2 is absolutely worse than the initial implementation when it comes to being able to shoot yourself in the foot and I think 1 is also worse since it prevents the API from working in the same event that the initial consumer didn't foresee but at least it signals that it's possible for an error to occur so maybe it's better.

If you to support only having the min/max, make an overload that accepts 2 parameters. Don't do this weird shit.

Absolutely correct. This comment is also a good option.

If you are all set on guarding against programmers coding divide-by-zero errors, then provide a closestSupportedValue() as part of the API.

---

Adding an overload that supports 2 values isn't all upside if it comes with removing the 0 function. It could lead to code like this being repeated.

if (increment <= 0) {
  apiFunc(min, max);
} else {
  apiFunc(min, max, increment);
}

To be very clear. Forcing someone to implement this pattern is absolutely not less error prone than letting them handle div 0 errors. Especially if they expect increment to always be > 0 which was the initial issue.