fix: add guard to if & unless helpers

[ErisDS]

This is a small proposed change that adds an error guard. I'm not too sure on wording though, which is basically 90% of the change 😂

Happy to update wording and add tests etc if it's seen as an OK change 👍

fixes #1548

[nknapp]

The first time I read it (and without having a look at your issue) I thought it might be breaking, but there are actually no new exception, just different ones. In all sane cases at least.

I actually like it. Better error messages are always good.

• There is a slight chance that someone has a template that actually works, because the second parameter passed in is an object with a valid fn function. I'm willing to ignore this case, because it is definitely not part of the documented API and seems very unlikely to me.
• Someone could be parsing the exception message, which I wouldn't consider part of the API as well.

This change should be generally safe.

The only way to be really sure is to apply the change, release it and roll back if someone complains. In my experience, breaking changes usually take less than a week to be noticed.

There are some things to consider:

• Should the check be for != 2 rather than > 2?
• Should similar code be added to the other built-in helpers as well?
• Maybe a custom exception class so that the exception can be parsed by surrounding code.
  • It could contain the expected and actual number of parameters as properties
  • It should have typings.

[nknapp]

@ErisDS despite my things to consider: If you add tests and fix the build, I will merge it.

[ErisDS]

Hey @nknapp, have updated this, adding tests and taking your feedback as far as I was able to for now.

What I did first was add a bunch of cases showing these inconsistent error messages for the if, unless and with helpers & commit that. I assume you'll squash this - it's just there to demonstrate the issues.

I've switched the logic from >2 to != 2 as you suggested, as I was able to find similar error cases for no arguments.

I've then added a commit that implements the guards and shows the error messages change to become consistent and hopefully a bit clearer.

No other tests have to change for this to pass, so if there are any edge cases they are undocumented and untested.

I've not gone as far as a custom Exception class & typings - this is a bit beyond what I'm confident with just now - I'm not familiar with TypeScript. However, I do have other work I'd like to do with error handling, so time-permitting I'll revisit this whole area with some more improvements soooooon.

For now, I think this is a small change which offers some improvement 🤞

[nknapp]

Hi @ErisDS. Thanks for the detailed explanation. I will have a look when I have some time.

[nknapp]

Thank you @ErisDS

I would release this in the next minor update, if that's ok. I haven't got a real plan yet about when that will be, but I don't want to release too often anymore unless it is a critical bug.

[ErisDS]

Yeah I’m in absolutely no rush 😬