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. |
|
@Cool-Katt how do you feel about this? |
|
I was kinda out of the loop on this one so I can review in more depth tomorrow, but preliminary assessment is that I would have liked to see a couple of more tests. I'll probably have to get up to speed first tho, to comment more |
|
Hi @Cool-Katt, okay I will add more tests, but I'll wait for your final assessment before adding more tests. |
| // | ||
|
|
||
| export const processString = (input) => { | ||
| throw new Error('Remove this line and implement the function'); |
There was a problem hiding this comment.
the way this currently is, it'll pass one of the tests by default, without the student changing anything.
| expect(() => processString(42)).toThrow(TypeError); | ||
| }); | ||
|
|
||
| xtest('throws Error message if string is empty', () => { |
There was a problem hiding this comment.
Idk if i'm vibing with this test specifically, maybe we need to add some handling for the empty string case, instead of throwing error.
In any case, more tests are needed, like for example do we want the tests to pass with any generic Error type or do we want to allow only certain types?
| An important point of programming is how to handle errors and close resources even if errors occur. | ||
|
|
||
| This exercise requires you to handle various errors. | ||
| Because error handling is rather programming language specific you'll have to refer to the tests for your track to see what's exactly required. |
There was a problem hiding this comment.
this line probably needs to be removed, or at least changed because it's generic from the problem-spec repo
|
|
||
| - If the input is not a string, throw a `TypeError`. | ||
|
|
||
| - If the input is an empty string, throw a generic `Error`. |
There was a problem hiding this comment.
how about on empty string, instead of throwing, it returns 'INVALID' or null/undefined so we can add some handling too.
we can also explicitly forbid the generic Error type to add more complexity
|
Right, sorry folks, real life got in the way. Anyway. The way I see it, currently its a good effort but i'd maybe like to see some more restrictions/explicit handling scenarios. It also definitely needs more tests and maybe a rewrite of the instructions. |
4 participants
Implemented the Error Handling practice exercise with solution, tests, and documentation