add error-handling exercise #2732
Conversation
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as outdated.
This comment was marked as outdated.
| 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'); |
There was a problem hiding this comment.
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.
…m/A-O-Emmanuel/javascript into implement-error-handling-exercise
…r-handling.spec.js
| @@ -0,0 +1,6 @@ | |||
| export const processString = (input) => { | |||
| //TODO: implement this | |||
There was a problem hiding this comment.
In all other stubs we throw new Error('...') (I don't recall the exact error message). We probably want to use that!
| throw new TypeError(); | ||
| } | ||
| if (input === '') { | ||
| throw new Error(); |
There was a problem hiding this comment.
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.
| @@ -0,0 +1,9 @@ | |||
| export const processString = (input) => { | |||
| if (typeof input !== 'string') { | |||
| throw new TypeError(); | |||
There was a problem hiding this comment.
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 <[email protected]>
|
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? |
|
@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(...) |
|
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. |
Implemented the Error Handling practice exercise with solution, tests, and documentation