Skip to content

add error-handling exercise#2732

Open
A-O-Emmanuel wants to merge 23 commits into
exercism:mainfrom
A-O-Emmanuel:implement-error-handling-exercise
Open

add error-handling exercise#2732
A-O-Emmanuel wants to merge 23 commits into
exercism:mainfrom
A-O-Emmanuel:implement-error-handling-exercise

Conversation

@A-O-Emmanuel
Copy link
Copy Markdown

Implemented the Error Handling practice exercise with solution, tests, and documentation

@github-actions

This comment has been minimized.

@github-actions github-actions Bot closed this Jul 24, 2025
@SleeplessByte SleeplessByte reopened this Jul 25, 2025
@SleeplessByte

This comment was marked as outdated.

@github-actions

This comment was marked as outdated.

@github-actions

This comment was marked as off-topic.

@github-actions

This comment was marked as outdated.

Comment thread exercises/practice/error-handling/.meta/proof.ci.js
Comment thread exercises/practice/error-handling/error-handling.js
Comment on lines +22 to +35
console.log = jest.fn();

try {
processString('');
} catch {
/*
intentionally left empty,
I expext this call to throw,
but only care about verifying that the finally block is executed
and clean up message logged.
*/
}

expect(console.log).toHaveBeenCalledWith('Resource cleaned up');
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will work with the Browser Test Runner, but the idea is not wrong. I can help come up with an easy alternative to fix this.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, thank you

Comment thread exercises/practice/error-handling/.meta/config.json Outdated
Copy link
Copy Markdown
Member

@BNAndras BNAndras left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not a track maintainer here, just a friendly maintainer from elsewhere on Exercism. I made some more general comments, but whatever SleeplessBytes and Cool-Kat say is the final word. :)

Comment thread exercises/practice/error-handling/error-handling.spec.js
Comment thread exercises/practice/error-handling/error-handling.spec.js Outdated
Comment thread exercises/practice/error-handling/error-handling.js Outdated
Comment thread exercises/practice/error-handling/error-handling.js Outdated
Comment thread exercises/practice/error-handling/error-handling.js Outdated
Comment thread exercises/practice/error-handling/error-handling.js Outdated
@A-O-Emmanuel A-O-Emmanuel requested a review from BNAndras August 2, 2025 23:16
Copy link
Copy Markdown
Member

@SleeplessByte SleeplessByte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's there is almost done. The only issue I have is that this isn't actually handling any error!

Comment thread exercises/practice/error-handling/error-handling.js Outdated
@@ -0,0 +1,6 @@
export const processString = (input) => {
//TODO: implement this
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In all other stubs we throw new Error('...') (I don't recall the exact error message). We probably want to use that!

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay

throw new TypeError();
}
if (input === '') {
throw new Error();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We almost always want a message in an error. We don't need to test the exact message, but throwing an empty error is non-idiomatic.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I'll add that

@@ -0,0 +1,9 @@
export const processString = (input) => {
if (typeof input !== 'string') {
throw new TypeError();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We almost always want a message in an error. We don't need to test the exact message, but throwing an empty error is non-idiomatic.

Co-authored-by: Derk-Jan Karrenbeld <derk-jan+github@karrenbeld.info>
@A-O-Emmanuel
Copy link
Copy Markdown
Author

Hi @SleeplessByte thanks for your review, sorry it took this long for me to reply, just to clarify, when you say "The only issue I have is that this isn't actually handling any error!" do you mean that the function should include descriptive error messages rather than handling more complex error scenarios?

@SleeplessByte
Copy link
Copy Markdown
Member

@A-O-Emmanuel no worries! We are not in a hurry.

Right now, the exercise wants you to throw errors. It doesn't want you to handle the error.

Handling errors could be:

try { } catch { }

or

promise.catch(...)

or

try { } finally { }

or

promise.finally(...)

@A-O-Emmanuel
Copy link
Copy Markdown
Author

Oh, that's true, I'll just have to revert back to the way I did it before. Thanks for the clarification, I've learnt something today, "throwing errors and handling errors" are two different things, yeah, it makes sense, thank you.

@A-O-Emmanuel
Copy link
Copy Markdown
Author

hi @Cool-Katt I've made changes and added more tests, please review, and sorry for the delay.

@A-O-Emmanuel
Copy link
Copy Markdown
Author

Hi @Cool-Katt have you been able to review the changes I made?

@Cool-Katt
Copy link
Copy Markdown
Contributor

@A-O-Emmanuel Terribly sorry for the long delay! It shouldn't have taken me 5 months to rely, yikes 😬

I still stand by my previous suggestion, which is:
I don't like to just throw a generic Error because that way the tests will pass by default without having changed the code at all, so I propose instead to throw a RangeError for the two cases that test length and maybe a SyntaxError for the case with mixed letters/numbers. We don't have to test for a specific message, but we can test for a specific type of error and weather or not a message was included at all (which it should be).
Also, there should be a test that fails in case a generic Error is thrown.

Let me know if you still want to work on this?

@A-O-Emmanuel
Copy link
Copy Markdown
Author

@Cool-Katt thanks for the comments, I will still work on it. by this weekend, I will create the commit with your suggestion, also, it's okay, I just thought you were busy. Thank you.

@A-O-Emmanuel
Copy link
Copy Markdown
Author

@Cool-Katt I've just push the changes you requested, please review

@A-O-Emmanuel
Copy link
Copy Markdown
Author

Hi @Cool-Katt @BNAndras @SleeplessByte @joshgoebel can anyone provide any feedback for this?

Copy link
Copy Markdown
Contributor

@Cool-Katt Cool-Katt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR for adding a new exercise should ideally only touch the files relevant to the new exercise being added, so please don't change any of the other files (even if it's just formatting, we have an auto formatter for this).

Also, see comments bellow

Comment thread exercises/practice/error-handling/.docs/introduction.md Outdated
Comment thread exercises/practice/error-handling/.docs/introduction.md
}

expect(error).toBeInstanceOf(Error);
expect(error.constructor).not.toBe(Error);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only need this check of the three, but testing for a message is good in any case because we don't ant people to circumvent sending one.

Also, i feel like this should be the first test, followed by all the tests for the various error types and finally the two passing cases that test the functionality

Copy link
Copy Markdown
Author

@A-O-Emmanuel A-O-Emmanuel May 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, thank you, and for the other files, sorry about that, It was mistake, I didn.t even know the formater ran for everyfile.

Comment thread config.json Outdated
"uuid": "de1c75f2-2461-4347-b5ca-b3cfaafe4d79",
"practices": [],
"prerequisites": [],
"difficulty": 1
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

set an appropriate difficulty level. You can cross reference on the site to see what level exercises show up al easy, medium or hard. (I don't remember the scale, sry)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'll do this later today, thank you

Comment thread exercises/practice/error-handling/error-handling.spec.js
@Cool-Katt
Copy link
Copy Markdown
Contributor

@A-O-Emmanuel Overall good stuff. Just needs a few very minor tweaks and we can finally merge this

@A-O-Emmanuel
Copy link
Copy Markdown
Author

HI @Cool-Katt I've implemented the changes you request, please check if they are up to the standard you want, thank you

@A-O-Emmanuel A-O-Emmanuel requested a review from Cool-Katt May 20, 2026 15:47
@A-O-Emmanuel
Copy link
Copy Markdown
Author

okay, doing that now

@Cool-Katt
Copy link
Copy Markdown
Contributor

@A-O-Emmanuel that was for the bot, but i got a typo. You don't have to do anything

@Cool-Katt
Copy link
Copy Markdown
Contributor

/format

@github-actions
Copy link
Copy Markdown
Contributor

The "Format code" action has started running.

@github-actions
Copy link
Copy Markdown
Contributor

The "Format code" action has finished running.

@github-actions
Copy link
Copy Markdown
Contributor

For security reasons, /format does not trigger CI builds when the PR has been submitted from a fork. If checks were not passing due to code format, trigger a build to make the required checks pass, through one of the following ways:

  • Push an empty commit to this branch: git commit --allow-empty -m "Trigger builds".
  • Close and reopen the PR.
  • Push a regular commit to this branch.

Copy link
Copy Markdown
Contributor

@Cool-Katt Cool-Katt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@A-O-Emmanuel
Copy link
Copy Markdown
Author

Okay, thank you

@A-O-Emmanuel
Copy link
Copy Markdown
Author

@Cool-Katt so it will be merged? or any other thing i need to do?

@Cool-Katt
Copy link
Copy Markdown
Contributor

@A-O-Emmanuel Nothing else for you to do right now.

If @SleeplessByte approves as well (since they requested some changes) we can merge this.

@A-O-Emmanuel
Copy link
Copy Markdown
Author

Okay, but I think @SleeplessByte was waiting for you to approve, let me send him a message

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants