[wingide-users] Getting "<error handling> <opaque error>" in the stack data view
rwarren at picarro.com
Mon Jan 16 11:57:50 EST 2006
Interesting... thanks for the detailed explanation and fix. I
cleared the stored values and it seems to have fixed the
As far as what was the root cause for that variable getting
flagged, it may have been a bad circular reference I
momentarily had in that routine that blew the stack. I actually
had an attribute reference (self.__dict__ I think) within the
self.__getattribute__ routine for a single execution. This is
obviously a bad idea. Could this have flagged the object?
A few additional comments on this...
On "Debug->Clear Stored Value Errors'...
- I didn't have any clue about this feature... likely because
I was entirely unaware about that debugger feature you have.
- The name makes sense once you understand what you are doing
with the debugger, but if you don't it seems cryptic to me.
Although maybe not entirely correct, you might want to
consider renaming it to "Clear Debugger Cache", although
this is clearly nitpicky. Now that I know wht it does
it obviously doesn't matter for me.
- This was only available while the debugger was running. It
would be nice to make it always available. One reason why:
I ran the code today to ensure the problem still existed
(it did, more on this below), stopped the program, tried
to clear it and it wasn't available, ran the program again
to the breakpoint, cleared stored erros, and the problem
still existed. Then I stopped, stepped in one line,
cleared errors, resumed to the breakpoint, and all was ok.
I'm not sure if I would have been stuck in a rut had I kept
running to the breakpoint or not. Hopefully that brutal
run-on description made sense?
On 'Force Reload'ing of variables...
- didn't know about this ability either
- When is another time you might use this? I can only think
of two cases: One where the debugger has a problem with
something (as I found), and the second if some other
thread may have modified the value...
- It would be nice were this available in the code pane, and
not just the Stack Data tab.
Another general comment is that this problem did not go away
on a completely fresh restart, so you obviously store this
information within the project data - This is now the second
carry-forward problem I've had with Wing. The first was the
source analysis losing sync with the actual source and making
the Source Assistant much less useful. You provided me a great
script that lets me re-anlyze a file with a right-click menu
option. A brute-force solution you should consider for the
future is an overall project clearing function that clears all
the time-saving carry-forward stuff you have in the project all
at once - the only thing that really needs to be preserved is
the files included in the project.
While I'm at it... it could be useful to have a project browser
that exposes (and advertises) some of the useful project/file
functionality you have and collects it all in one location.
Maybe an additional tab in the Project->Properties dialog
called "Stored settings" that lets you see the following (for
- Problem variables
- Stored breakpoints
- Ignored exceptions
- Font size
- Run arguments on debug
- ??? whatever else you store per file
In addition these functions could be there (per file):
- Re-analyze file
- Clear stored errors (clear debugger cache?)
- Restore default editor settings
- Clear all project data
In addition to being useful, I think this might also be a nice
demonstartion of some of the more useful features you have
built into Wing that we don't know about until we run into
Thanks again - apologies for the extended ramble-mail.
From: Wingware Support [mailto:support at wingware.com]
Sent: Sunday, January 15, 2006 1:36 PM
To: Russell Warren
Cc: wingide-users at wingware.com
Subject: Re: [wingide-users] Getting "<error handling> <opaque error>"
in the stack data view
On Fri, 13 Jan 2006, Russell Warren wrote:
> I've been getting what I consider to be a strange <opaque
> error> in the stack data view with some code that I'm working
> on. I've steadily hacked and slashed the code down to a
> reduced segment that still shows the problem (if not making
> much sense to look at). The code is at the end of this.
> With a breakpoint at the last code line, what happens is that
> the fff object appears with the opaque error for some reason I
> don't understand. What is up here? It doesn't seem to match
> the description that exists in the help docs of the opaque
> error. This code works completely fine and I can even step
> through it all neatly in Wing.
> Any explanation (or fix, so I can see the object) is
The code sample you sent works fine for me. Try Clear Stored
Value Errors from the Debug menu. If you don't restart the debug
process, you'll also need to right-click on the value and Force
What is going on here is that fff did at some point contain
something that Wing's debugger data value packaging code choked
on, and Wing remembers this to avoid trying to poke values that
act unexpectedly -- doing so can cause crashing (in buggy C
extension module code) or sometimes length hanging depending on
what is wrong with the user code being exercised by the debugger.
We've learned over the years that avoiding oddly behaving values
is the better course to take, although you can of course
un-ignored them with Clear Stored Value Errors.
This is kind of weird but it's unavoidable in the context of a
highly dynamic introspective language like Python. Fortunately
such problems also seem relatively rare in practice.
In this case, my guess is that at some point in your development,
__getattribute__ for '__dict__' returned something that was not a
dict, but it could have been something similar like an unusual
exception raised by __getattribute__.
Hope that helps to clarify it. If you figure out the specific
case that caused it, please let us know. There may still be
scenarios we can guard against more conservatively than just
giving up on the value.
Wing IDE for Python
Advancing Software Development
More information about the wingide-users