Re: Minor API changes in 10-year-old module

Are all the changes only related to die vs. return error codes? A fatal error is pretty easy to make non-fatal with eval {}, so it sounds like it wouldn't be too difficult to make your code have exactly the same API as the old module, or would it? If it's easy, then perhaps you could even consider making whether errors are fatal or not a configuration option.

I wouldn't worry all too much about people relying on $@ values, unless specific $@ values have been documented in the module's docs.

BTW, I think it's ok if you name the module, that might help, it's all open source anyway :-)

Comment on Re: Minor API changes in 10-year-old module Select or Download Code

Replies are listed 'Best First'.
Re^2: Minor API changes in 10-year-old module by wanna_code_perl (Friar) on Sep 05, 2019 at 18:52 UTC
The API changes I've made are deliberate, and ultimately for the good of the project. As an example of why I made these changes, there was a method that would: `return 0;` if certain arguments are invalid, `croak()`s if others are invalid, `carp "Connection failed"; return 0;` on connection failures. Yes, `carp()`, and Not trap upstream exceptions itself, so it would `die` for any number of undocumented reasons the author did not anticipate (and no unit tests either!) Since returning non-zero had no semantic meaning beyond "nothing broke," and the distinction between `return 0;` v. `croak()` was already ill-defined, I changed this sub to always `croak()` on error, thinking most implementations would already be `eval{...}`-ing that call, or risk premature death. That's the biggest change. The other 3-4 examples are similar but simpler (fewer cases). The documentation for the methods was generally good, except when it came to error handling. So I'm not really even going against the existing documentation, here, though I'm not using that as an excuse to break people's code. :-) BTW, I think it's ok if you name the module, that might help, it's all open source anyway :-) My personal choice. I'm not naming the module out of respect for the original author. I have not been able to reach them, and don't want them to hear about my feedback via this thread. I trust I've described the differences well enough for the general advice I'm asking for. (If not, please let me know!)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Minor API changes in 10-year-old module
by wanna_code_perl (Friar) on Sep 05, 2019 at 18:52 UTC

The API changes I've made are deliberate, and ultimately for the good of the project. As an example of why I made these changes, there was a method that would:

return 0; if certain arguments are invalid, croak()s if others are invalid,
carp "Connection failed"; return 0; on connection failures. Yes, carp(), and
Not trap upstream exceptions itself, so it would die for any number of undocumented reasons the author did not anticipate (and no unit tests either!)

Since returning non-zero had no semantic meaning beyond "nothing broke," and the distinction between return 0; v. croak() was already ill-defined, I changed this sub to always croak() on error, thinking most implementations would already be eval{...}-ing that call, or risk premature death.

That's the biggest change. The other 3-4 examples are similar but simpler (fewer cases).

The documentation for the methods was generally good, except when it came to error handling. So I'm not really even going against the existing documentation, here, though I'm not using that as an excuse to break people's code. :-)

BTW, I think it's ok if you name the module, that might help, it's all open source anyway :-)

My personal choice. I'm not naming the module out of respect for the original author. I have not been able to reach them, and don't want them to hear about my feedback via this thread. I trust I've described the differences well enough for the general advice I'm asking for. (If not, please let me know!)

[reply]
[d/l]
[select]