Python debugging in eclipse stop on outer except block












0















I have nested exceptions handling in my code, when inner blocks do some stuff before re-raising the exception to upper layers.
Traceback always reports the line number that started the exception handling.
However, when running in UI debugger (Pydev/Eclipse) it stops on the outer exception block in some cases.



Consider the following code for example:



import sys

def f(a):
c=5/a
return c

def sub(d):
print("Entered sub(%d)" % d)
try:
print("Entered try @sub")
e = f(d)/(d-1)
return e
except:
print("Do some staff before re-raising the exception upwards")
raise

def main():
try:
print("Entered try @main")
d = int(sys.argv[1])
sub(d)
except:
print("Reached except block @main")
raise

if __name__ == '__main__':
main()


When running with argument = 0, the exception is caused at line#4 and the debugger stops on that line:
Correct exception trapping



However, when running with argument = 1, the exception is caused at line#11 (as reported in the printed traceback) but the debugger stops at line#15.



Wrong exception trapping



Once the debugger stops at the incorrect location it is very difficult to watch internal variables and handle the error, especially when the code in the try block uses loops.



In Pydev->Manage Exceptions, I checked only the "suspend on uncaught exceptions".

There is a checkbox "Skip exceptions caught in same function" that seem related (because it seems like the debugger skipped the first exception in sub and stopped on "raise" statement which can be considered another exception in same function, although the documentation says that it should re-raise the same exception).

This checkbox is grayed out unless I first check "Suspend on caught exceptions*", but once enabling it the debugger gets stuck and does not stop anywhere...



Will appreciate your help.



-Moshe










share|improve this question













migrated from superuser.com Jan 2 at 8:48


This question came from our site for computer enthusiasts and power users.



















  • Anyone has some insights about this?

    – Moshe
    Jan 3 at 9:32













  • Can you comment whether this is the right forum for my question?

    – Moshe
    Jan 7 at 7:42
















0















I have nested exceptions handling in my code, when inner blocks do some stuff before re-raising the exception to upper layers.
Traceback always reports the line number that started the exception handling.
However, when running in UI debugger (Pydev/Eclipse) it stops on the outer exception block in some cases.



Consider the following code for example:



import sys

def f(a):
c=5/a
return c

def sub(d):
print("Entered sub(%d)" % d)
try:
print("Entered try @sub")
e = f(d)/(d-1)
return e
except:
print("Do some staff before re-raising the exception upwards")
raise

def main():
try:
print("Entered try @main")
d = int(sys.argv[1])
sub(d)
except:
print("Reached except block @main")
raise

if __name__ == '__main__':
main()


When running with argument = 0, the exception is caused at line#4 and the debugger stops on that line:
Correct exception trapping



However, when running with argument = 1, the exception is caused at line#11 (as reported in the printed traceback) but the debugger stops at line#15.



Wrong exception trapping



Once the debugger stops at the incorrect location it is very difficult to watch internal variables and handle the error, especially when the code in the try block uses loops.



In Pydev->Manage Exceptions, I checked only the "suspend on uncaught exceptions".

There is a checkbox "Skip exceptions caught in same function" that seem related (because it seems like the debugger skipped the first exception in sub and stopped on "raise" statement which can be considered another exception in same function, although the documentation says that it should re-raise the same exception).

This checkbox is grayed out unless I first check "Suspend on caught exceptions*", but once enabling it the debugger gets stuck and does not stop anywhere...



Will appreciate your help.



-Moshe










share|improve this question













migrated from superuser.com Jan 2 at 8:48


This question came from our site for computer enthusiasts and power users.



















  • Anyone has some insights about this?

    – Moshe
    Jan 3 at 9:32













  • Can you comment whether this is the right forum for my question?

    – Moshe
    Jan 7 at 7:42














0












0








0








I have nested exceptions handling in my code, when inner blocks do some stuff before re-raising the exception to upper layers.
Traceback always reports the line number that started the exception handling.
However, when running in UI debugger (Pydev/Eclipse) it stops on the outer exception block in some cases.



Consider the following code for example:



import sys

def f(a):
c=5/a
return c

def sub(d):
print("Entered sub(%d)" % d)
try:
print("Entered try @sub")
e = f(d)/(d-1)
return e
except:
print("Do some staff before re-raising the exception upwards")
raise

def main():
try:
print("Entered try @main")
d = int(sys.argv[1])
sub(d)
except:
print("Reached except block @main")
raise

if __name__ == '__main__':
main()


When running with argument = 0, the exception is caused at line#4 and the debugger stops on that line:
Correct exception trapping



However, when running with argument = 1, the exception is caused at line#11 (as reported in the printed traceback) but the debugger stops at line#15.



Wrong exception trapping



Once the debugger stops at the incorrect location it is very difficult to watch internal variables and handle the error, especially when the code in the try block uses loops.



In Pydev->Manage Exceptions, I checked only the "suspend on uncaught exceptions".

There is a checkbox "Skip exceptions caught in same function" that seem related (because it seems like the debugger skipped the first exception in sub and stopped on "raise" statement which can be considered another exception in same function, although the documentation says that it should re-raise the same exception).

This checkbox is grayed out unless I first check "Suspend on caught exceptions*", but once enabling it the debugger gets stuck and does not stop anywhere...



Will appreciate your help.



-Moshe










share|improve this question














I have nested exceptions handling in my code, when inner blocks do some stuff before re-raising the exception to upper layers.
Traceback always reports the line number that started the exception handling.
However, when running in UI debugger (Pydev/Eclipse) it stops on the outer exception block in some cases.



Consider the following code for example:



import sys

def f(a):
c=5/a
return c

def sub(d):
print("Entered sub(%d)" % d)
try:
print("Entered try @sub")
e = f(d)/(d-1)
return e
except:
print("Do some staff before re-raising the exception upwards")
raise

def main():
try:
print("Entered try @main")
d = int(sys.argv[1])
sub(d)
except:
print("Reached except block @main")
raise

if __name__ == '__main__':
main()


When running with argument = 0, the exception is caused at line#4 and the debugger stops on that line:
Correct exception trapping



However, when running with argument = 1, the exception is caused at line#11 (as reported in the printed traceback) but the debugger stops at line#15.



Wrong exception trapping



Once the debugger stops at the incorrect location it is very difficult to watch internal variables and handle the error, especially when the code in the try block uses loops.



In Pydev->Manage Exceptions, I checked only the "suspend on uncaught exceptions".

There is a checkbox "Skip exceptions caught in same function" that seem related (because it seems like the debugger skipped the first exception in sub and stopped on "raise" statement which can be considered another exception in same function, although the documentation says that it should re-raise the same exception).

This checkbox is grayed out unless I first check "Suspend on caught exceptions*", but once enabling it the debugger gets stuck and does not stop anywhere...



Will appreciate your help.



-Moshe







python eclipse debugging exception






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 2 at 7:25









MosheMoshe

24




24




migrated from superuser.com Jan 2 at 8:48


This question came from our site for computer enthusiasts and power users.









migrated from superuser.com Jan 2 at 8:48


This question came from our site for computer enthusiasts and power users.















  • Anyone has some insights about this?

    – Moshe
    Jan 3 at 9:32













  • Can you comment whether this is the right forum for my question?

    – Moshe
    Jan 7 at 7:42



















  • Anyone has some insights about this?

    – Moshe
    Jan 3 at 9:32













  • Can you comment whether this is the right forum for my question?

    – Moshe
    Jan 7 at 7:42

















Anyone has some insights about this?

– Moshe
Jan 3 at 9:32







Anyone has some insights about this?

– Moshe
Jan 3 at 9:32















Can you comment whether this is the right forum for my question?

– Moshe
Jan 7 at 7:42





Can you comment whether this is the right forum for my question?

– Moshe
Jan 7 at 7:42












0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54003444%2fpython-debugging-in-eclipse-stop-on-outer-except-block%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54003444%2fpython-debugging-in-eclipse-stop-on-outer-except-block%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

android studio warns about leanback feature tag usage required on manifest while using Unity exported app?

SQL update select statement

'app-layout' is not a known element: how to share Component with different Modules