Keeping debugger out of "other" files

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Keeping debugger out of "other" files

Michael Hipp
Is there any way to tell the debugger to never go outside my project files to
display the location of an unhanded exception.

Frequently it will dive deep into some of the core packages for wxPython to
report a bug that is actually in my own code. It would be safer and more
useful to stick to the files in the project. If you're not paying attention
you can mistakenly be editing some far flung file outside the project. Plus,
it has now taken me to a place where the actual error probably is not and I
have to make my way back.

Thanks,
Michael
_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide
Reply | Threaded
Open this post in threaded view
|

Re: Keeping debugger out of "other" files

Luc J. Bourhis

On 13 Aug 2005, at 01:27, Michael Hipp wrote:
Is there any way to tell the debugger to never go outside my project files to 
display the location of an unhanded exception.

Frequently it will dive deep into some of the core packages for wxPython to 
report a bug that is actually in my own code. It would be safer and more 
useful to stick to the files in the project. If you're not paying attention 
you can mistakenly be editing some far flung file outside the project. Plus, 
it has now taken me to a place where the actual error probably is not and I 
have to make my way back.

As far as I know Python does not provide an easy way to throw a exception from higher in the stack trace than the line of code where the problem has occurred, in the manner the Carp module does it in Perl, which is a pity since pre-condition violations are nearly always better signalled in the calling code than in the callee for example.

Since Python does not provide this feature, it would indeed be nice if the debugger could do so. I would reckon two alternatives: clim the stack until (a) one has moved out of the faulty module and (b) one has moved out of the faulty package.

Luc Bourhis

_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keeping debugger out of "other" files

Michael Hipp
Luc Bourhis wrote:

> On 13 Aug 2005, at 01:27, Michael Hipp wrote:
> Is there any way to tell the debugger to never go outside my project
> files to
> display the location of an unhanded exception.
>
> Frequently it will dive deep into some of the core packages for wxPython to
> report a bug that is actually in my own code. It would be safer and more
> useful to stick to the files in the project. If you're not paying attention
> you can mistakenly be editing some far flung file outside the project.
> Plus,
> it has now taken me to a place where the actual error probably is not and I
> have to make my way back.
>
> As far as I know Python does not provide an easy way to throw a
> exception from higher in the stack trace than the line of code where the
> problem has occurred, in the manner the Carp module does it in Perl,
> which is a pity since pre-condition violations are nearly always better
> signalled in the calling code than in the callee for example.
>
> Since Python does not provide this feature, it would indeed be nice if
> the debugger could do so. I would reckon two alternatives: clim the
> stack until (a) one has moved out of the faulty module and (b) one has
> moved out of the faulty package.

To me, knowing nothing of the internals of Wing IDE, it would be a
fairly simple matter to climb upwards until it finds it is in a file
that is a part of the project.

Thanks,
Michael
_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide
Reply | Threaded
Open this post in threaded view
|

Re: Keeping debugger out of "other" files

Tom Stambaugh
In reply to this post by Michael Hipp
Perhaps you can put your code in a try block and catch everything that
happens within it. Then, reraise your own exception along with a reference
to the original. I'm naive about python, but this is a fairly common idiom
in Java. Look at unittest.py -- specifically unittest.TestCase.run() -- for
something similar.

Thanks,
Tom

----- Original Message -----
From: "Michael Hipp" <[hidden email]>
To: <[hidden email]>
Sent: Friday, August 12, 2005 7:27 PM
Subject: [wingide-users] Keeping debugger out of "other" files


> Is there any way to tell the debugger to never go outside my project files
> to
> display the location of an unhanded exception.
>
> Frequently it will dive deep into some of the core packages for wxPython
> to
> report a bug that is actually in my own code. It would be safer and more
> useful to stick to the files in the project. If you're not paying
> attention
> you can mistakenly be editing some far flung file outside the project.
> Plus,
> it has now taken me to a place where the actual error probably is not and
> I
> have to make my way back.
>
> Thanks,
> Michael
> _________________________________________________
> Wing IDE users list
> http://wingware.com/lists/wingide
>
>




_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide
Reply | Threaded
Open this post in threaded view
|

Re: Keeping debugger out of "other" files

Wing IDE Support
In reply to this post by Michael Hipp
On Mon, 15 Aug 2005, Michael Hipp wrote:

> Luc Bourhis wrote:
> > On 13 Aug 2005, at 01:27, Michael Hipp wrote:
> > Is there any way to tell the debugger to never go outside my project
> > files to
> > display the location of an unhanded exception.
> >
> > Frequently it will dive deep into some of the core packages for wxPython to
> > report a bug that is actually in my own code. It would be safer and more
> > useful to stick to the files in the project. If you're not paying attention
> > you can mistakenly be editing some far flung file outside the project.
> > Plus,
> > it has now taken me to a place where the actual error probably is not and I
> > have to make my way back.
> >
> > As far as I know Python does not provide an easy way to throw a
> > exception from higher in the stack trace than the line of code where the
> > problem has occurred, in the manner the Carp module does it in Perl,
> > which is a pity since pre-condition violations are nearly always better
> > signalled in the calling code than in the callee for example.
> >
> > Since Python does not provide this feature, it would indeed be nice if
> > the debugger could do so. I would reckon two alternatives: clim the
> > stack until (a) one has moved out of the faulty module and (b) one has
> > moved out of the faulty package.
>
> To me, knowing nothing of the internals of Wing IDE, it would be a
> fairly simple matter to climb upwards until it finds it is in a file
> that is a part of the project.

In fact Wing already does this internally to omit frames within our
own debugger modules, which are usually present.  I think the
suggestion is a good mode to implement, although it will work better
and seem more robust after we have projects that auto-update the files
within directories.  Otherwise a new module would arbitrarily be
omitted, and that could get confusing.  Also, I'm not sure we should
trim off frames, but just start by default in your own code.  
Otherwise, it would be confusing when you do in fact uncover a bug in
a library, or need access to the library code in order to understand
and fix the bug in your code.

- Stephan
_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide
Reply | Threaded
Open this post in threaded view
|

Re: Keeping debugger out of "other" files

Luc J. Bourhis
In reply to this post by Michael Hipp

On 15 Aug 2005, at 15:43, Michael Hipp wrote:

Luc Bourhis wrote:

[…]. I would reckon two alternatives: clim the 
stack until (a) one has moved out of the faulty module and (b) one has 
moved out of the faulty package.


To me, knowing nothing of the internals of Wing IDE, it would be a 
fairly simple matter to climb upwards until it finds it is in a file 
that is a part of the project.

In a fairly complex project, one may debug either a module or the client code using that module. The exception being reported as you suggest would not fulfil the latter case for the exception would always be reported in the faulty module. Note that I suggested skipping all the files in the package where the exception occurred so that barring the package “wx” would address your problem. These two alternatives, skipping a module or a package seem flexible enough to fit most common cases.

Luc Bourhis

_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keeping debugger out of "other" files

Luc J. Bourhis
In reply to this post by Wing IDE Support

On 15 Aug 2005, at 16:21, Wingware Support wrote:

> On Mon, 15 Aug 2005, Michael Hipp wrote:
>
>> Luc Bourhis wrote:
>>
>>> [...]

>>> As far as I know Python does not provide an easy way to throw a
>>> exception from higher in the stack trace than the line of code  
>>> where the
>>> problem has occurred, in the manner the Carp module does it in Perl,
>>> which is a pity since pre-condition violations are nearly always  
>>> better
>>> signalled in the calling code than in the callee for example.
>>>
>>> Since Python does not provide this feature, it would indeed be  
>>> nice if
>>> the debugger could do so. I would reckon two alternatives: clim the
>>> stack until (a) one has moved out of the faulty module and (b)  
>>> one has
>>> moved out of the faulty package.
>>>
>>
>> To me, knowing nothing of the internals of Wing IDE, it would be a
>> fairly simple matter to climb upwards until it finds it is in a file
>> that is a part of the project.
>>
>
> In fact Wing already does this internally to omit frames within our
> own debugger modules, which are usually present.
That I never noticed it is a tribute to your implementation of that  
feature!

> I think the
> suggestion is a good mode to implement, although it will work better
> and seem more robust after we have projects that auto-update the files
> within directories.  Otherwise a new module would arbitrarily be
> omitted, and that could get confusing.

It is another reason I would prefer to explicitly spell out which  
modules or packages to skip in the frames stack.

> Also, I'm not sure we should
> trim off frames, but just start by default in your own code.
> Otherwise, it would be confusing when you do in fact uncover a bug in
> a library, or need access to the library code in order to understand
> and fix the bug in your code.

I concur

>
> - Stephan
> _________________________________________________
> Wing IDE users list
> http://wingware.com/lists/wingide
>


_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide

smime.p7s (3K) Download Attachment