1

Traceback is printed to Debug I/O window after exception reported.

Debugger:Exception settings are

Report Exceptions: When Printed
Report Logged Exceptions In When Printed Mode: True

In my exception handler I am logging the exception with logging.exception(...) so the debugger stops at the logging statement (as expected) and the logging output has been displayed in the Debug I/O window. The Exceptions toolbox window also shows a stack trace which is navigable by clicking (really nice by the way).The problem is that when I continue another stack trace is printed to the Debug I/O window. This behavior is different than what I would see on stderr when running the code from a console.

Behavior remains even if I ignore this exception location from the Exceptions tool.Wing version 5.1.12 (I plan on upgrading soon)Python 2.7.14Windows 10

Thanks

Max Slimmer's avatar
31
Max Slimmer
asked 2018-05-19 12:04:00 -0600
Wingware Support's avatar
4.2k
Wingware Support
updated 2020-01-22 19:56:19 -0600
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

3 Answers

1

I'm currently seeing this bug in 9.1.2.1 (rev a76268badf6d). If it helps I'm raising an exception inside the scope of a relevant pytest.raises context manager. When I try to access the exception value in the debug console I'm told that isn't allowed until the context manager is complete.

The stack trace in the debug window appears to be in some sort of markup language, as follows.

<exception syntax="no"> <traceback> <frame lineno="341" filename="/Users/sholden/.venvs/meshtastic/lib/python3.10/site-packages/_pytest/runner.py" name="from_call"> result: Optional[TResult] = func()</frame> <frame lineno="241" filename="/Users/sholden/.venvs/meshtastic/lib/python3.10/site-packages/_pytest/runner.py" name="&lt;lambda&gt;"> lambda: runtest_hook(item=item, **kwds), when=when, reraise=reraise</frame> <frame lineno="502" filename="/Users/sholden/.venvs/meshtastic/lib/python3.10/site-packages/pluggy/_hooks.py" name="__call__"> return self._hookexec(self.name, self._hookimpls.copy(), kwargs, firstresult)</frame> <frame lineno="120" filename="/Users/sholden/.venvs/meshtastic/lib/python3.10/site-packages/pluggy/_manager.py" name="_hookexec"> return self._inner_hookexec(hook_name, methods, kwargs, firstresult)</frame> ... filename="/opt/homebrew/Cellar/python@3.10/3.10.13/Frameworks/Python.framework/Versions/3.10/lib/python3.10/unittest/mock.py" name="patched"> return func(*newargs, **newkeywargs)</frame> <frame lineno="60" filename="/Users/sholden/Projects/meshtastic/python/meshtastic/tests/test_serial_interface.py" name="test_SerialInterface_multiple_ports"> SerialInterface(noProto=True)</frame> <frame lineno="41" filename="/Users/sholden/Projects/meshtastic/python/meshtastic/serial_interface.py" name="__init__"> raise OSError(</frame> </traceback> </exception>

Steve Holden's avatar
61
Steve Holden
answered 2024-04-22 11:52:53 -0600
edit flag offensive 0 remove flag delete link

Comments

Apologies, I now realise I should have added this as a comment.

Steve Holden's avatar Steve Holden (2024-04-22 11:53:53 -0600) edit

Could you send a test case to support@wingware.com?

Wingware Support's avatar Wingware Support (2024-04-23 05:11:42 -0600) edit
add a comment see more comments
0

It was mostly an annoyance while debugging but its awesome that it turned up a more significant issue. Now I just have to get onto version 6 to get the patch. :)

Max Slimmer's avatar
31
Max Slimmer
answered 2018-05-21 15:10:00 -0600
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments
0

I'm seeing this also.  I think we must be printing it again from the debugger code that handles this case, but I'm not sure yet.  We'll try to fix this soon.  Thanks for reporting this problem!

Wingware Support's avatar
4.2k
Wingware Support
answered 2018-05-21 09:07:00 -0600
edit flag offensive 0 remove flag delete link

Comments

We've issued a patch for Wing 6.0.12 that fixes this.  You can get it with Check for Updates from the Help menu.  The issue was that we were calling the sys.excepthook incorrectly during handling of logging.error.  This is relatively harmless with the default sys.excepthook but could be bad in code that sets a custom excepthook, so patching it seemed best.  Thanks again for reporting this!

Wingware Support's avatar Wingware Support (2018-05-21 13:24:00 -0600) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer