-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Error-Handling]: instructions are unclear, and wrong programs pass the tests #1780
Comments
The problem with the test example is that the
However, that is limited to checking whether the exception class name is referenced somewhere in the entire function, and not just the statement that actually raised it. |
The entire |
Yeah, this exercise needs a complete rethink. My best thought is that the dummy file include something like this: # do not change the UnhappyError, but be prepared to handle it below.
class UnhappyError(Exception):
pass
def convert_unhappy_to_none(func, *args, **kwargs):
# you may move the following line, but it _must_ appear in your function
return func(*args, **kwargs)
def convert_unhappy_to_bool(func, *args, **kwargs):
# you may move the following line, but it _must_ appear in your function
return func(*args, **kwargs)
def convert_unhappy_to_error_code(func, *args, **kwargs):
# you may move the following line, but it _must_ appear in your function
return func(*args, **kwargs)
def convert_unhappy_to_typeerror(func, *args, **kwargs):
# you may move the following line, but it _must_ appear in your function
return func(*args, **kwargs) The test file can then import the UnhappyError and generate mocks that will raise it as a side_effect in appropriate circumstances. Then we'd just need tests to validate that everything worked when no error was raised as well as when an UnhappyError was raised ... we can probably relax our usual habit of ignoring what's actually in an error message and simply write the exercise so the student MUST pass-through the message the tests put into the UnhappyError verbatim when converting to a new error type. |
If you are going to go that far, don't forget to include having to use the three types of Thinking about this, it could almost be step 2 of another exercise. For example, a tour of the built-in functions or types. In the example, step one is doing the conversions and calls with normal input (e.g. turn "123" into 123 or bool(None) == False), and this step two is the same but with bad calls or raised exceptions (int("football") or set(123) raises an exception) to teach people how to handle them before things get too complicated. I'm not married to the idea of the built-ins, but it shows the general concept of extending a previous exercise. |
I noticed this yesterday! I understand that the v3 version of the track will have a new version of this exercise, but could we fix this in the interim with more descriptive hints? As it stands the student is left without a real direction to move to pass the tests, without just trying stuff out. If the intent is to show how to use Edit - Glad to submit a PR if that makes sense for a short term fix. |
@morganpartee -- Thanks so much for volunteering to help clarify this exercise! Since we are close to launching a beta of V3 (within the next two months), and it looks like this exercise needs a complete re-work, we've decided to mark it as deprecated (which will remove it from the website for the Python track) until we can get both the V3 error-handling concept exercises completed and the re-write of this exercise completed. We would love if you'd like to help with either the V3 concept exercises or a re-write of this practice exercise...we just don't want you to do a bunch of "short-term fix" work that won't get used. If you would like to take on either the V3 exercises or a re-write of this one, please reach out and let us know. Thanks again. |
Per discussions on [issue 1780](#1780), the `error-handling` exercise probably needs a full re-write. Until that can be completed, we're deprecating the exercise for the Python track.
Thanks @BethanyG! I'll definitely join in on v3. I'm behind the curve on developments there, but I'm glad to help. |
* Marking `error-handling` Side Exercise Deprecated Per discussions on [issue 1780](#1780), the `error-handling` exercise probably needs a full re-write. Until that can be completed, we're deprecating the exercise for the Python track. * Changed topics to null for deprecated exercise * Changed unlock & difficulty params for error-handling Exercise has be deprecated. * remove trailing whitespace Co-authored-by: Corey McCandless <cmccandless@users.noreply.github.com>
@cmccandless -- I think this would be good to leave open as a reminder. Otherwise, it might get lost in the shuffle. Ultimately, we want to log both the error-handling concept exercise issues and a re-write of this practice exercise as its own issue, but I don't have time atm to do so -- so I think the best bet is to leave this pending. |
This issue has been automatically marked as |
See also #2275 for additional considerations for the |
I just did the error-handling exercise, and had several issues:
int
was the right thing to try, but this is not mentioned in the readme or the stubs.The text was updated successfully, but these errors were encountered: