Skip to content
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

Exceptions that take more than one argument fail #18

Open
max-sixty opened this issue Mar 4, 2016 · 1 comment
Open

Exceptions that take more than one argument fail #18

max-sixty opened this issue Mar 4, 2016 · 1 comment

Comments

@max-sixty
Copy link

Here: https://github.com/flavioamieiro/nose-ipdb/blob/master/ipdbplugin.py#L62, which supplies a single argument.

For example:

from boto.exception import S3ResponseError
S3ResponseError??

Init signature: S3ResponseError(self, status, reason, body=None)
Source:
class S3ResponseError(StorageResponseError):
    """
    Error in response from S3.
    """
    pass

File:           /usr/local/lib/python2.7.11/lib/python2.7/site-packages/boto/exception.py
Type:           type

Thanks for the wonderful package!

@flavioamieiro
Copy link
Owner

Thanks for the report @MaximilianR

I'm looking into it, but didn't manage to write a fix yet. I seems like you're triggering #16, that's why you're falling into this if statement in line 62. So, as a temporary workaround, if you can get rid of any print statements or anything else in the test that writes to stdout you would probably no hit this bug.

I'll upload a fix as soon as I find a way to get the original arguments in the context nose gives to me.

flavioamieiro added a commit that referenced this issue Mar 18, 2016
This issue happens when there is captured stdout (so nose gives us the
exception value as a string instead of an exception object) and we try to
instantiate it using the exception class (we do that as a workaround for #16).
If the exception needs more than one argument to be instantiated, it will
receive only one (the string with the captured output).

I still need to find a fix for this, but it may very well be a change in the
way we use traceback.print_exception since we don't seem to have access to the
original exception arguments here.
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

No branches or pull requests

2 participants