two-fer: detect and block stub throw implementations

[samirhssn]

Summary

Detects placeholder implementations in the two-fer exercise that throw
new Error("Please implement …") and blocks them.

Details

• Adds a reusable hasStubThrow utility to detect stub throw patterns
• Introduces an actionable comment to tell students to remove dead stub code
• Integrates the check into the two-fer analyzer flow
• All existing tests pass

Motivation

Stub throw implementations are not valid solutions but were previously allowed.
This change ensures they are caught early and feedback is clear.

[github-actions]

Hello. Thanks for opening a PR on Exercism 🙂

We ask that all changes to Exercism are discussed on our Community Forum before being opened on GitHub. To enforce this, we automatically close all PRs that are submitted. That doesn't mean your PR is rejected but that we want the initial discussion about it to happen on our forum where a wide range of key contributors across the Exercism ecosystem can weigh in.

You can use this link to copy this into a new topic on the forum. If we decide the PR is appropriate, we'll reopen it and continue with it, so please don't delete your local branch.

If you're interested in learning more about this auto-responder, please read this blog post.

---

Note: If this PR has been pre-approved, please link back to this PR on the forum thread and a maintainer or staff member will reopen it.

[SleeplessByte]

I'm happy to take a look at this. Could you follow the bot's instructions? I'm keen to reopen this.

[samirhssn]

I’ve opened a discussion on the Exercism Community Forum as requested:

https://forum.exercism.org/t/proposal-block-stub-throw-implementations-in-two-fer-analyzer/20383

Please let me know if this proposal is approved and the PR can be reopened.

[IsaacG]

Per the forum thread, checking for a single-line throw-function isn't helpful as the tests would fail and the analyzer would never run.

[samirhssn]

Thanks for the clarification.

If stub throw new Error(...) implementations never reach the analyzer because the tests fail first, then I agree this check is unnecessary.

I’m happy to close this PR unless there’s a scenario where the analyzer can run on such solutions.

[samirhssn]

I’ve updated hasStubThrow to also detect unreachable stub throws that appear after a guaranteed terminating statement (return).

This covers cases where tests pass but a leftover throw new Error(...) remains as dead code.

The detection is intentionally conservative (no control-flow analysis, no branching) and limited to clearly unreachable cases.

[samirhssn]

Thanks, that makes sense.

I agreed, for two-fer the stub throw is uniform and does not require control-flow or reachability analysis.

I will simplify the implementation to a direct AST match for:
throw new Error("Please implement…")
anywhere in the function body, and drop the dead-code / sequencing logic.

I will push a reduced version focused purely on detecting the canonical stub throw.

[SleeplessByte]

This is great!

Two more things:

1. Can you please add a test file with (at least) two tests:
   • one where there is a stub present (I would literally copy a stub from the js repo) and it fails because of that
   • one with a regular error, but no stub code (and passes)
2. Open a PR on website-copy to add the comment you need for this to the website? Link it here, so we can merge both back-2-back.

[samirhssn]

Tests for stub throw detection have been added.
Website-copy PR is linked here: exercism/website-copy#2390

[SleeplessByte]

/format

[github-actions]

The "Format code" action has started running.

[SleeplessByte]

Cannot auto-format because this is main on the fork.

All that's left is running the formatted @samirhssn! Everything looks good.

[samirhssn]

Thanks for the review and approval.

Noted on the formatting check. Since this PR is from a fork, I’ll leave it as-is for now.
I can rebase or apply formatting locally if needed.

[SleeplessByte]

Yes, please apply the formatter locally, and push, so the checks pass.