|
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|
|
Stop making mediocre tutorials.The best tutorials are video! Camtasia Studio makes it easy to create engaging, buzz-building screen videos at any size, in any popular format. Download the free trial!
|
|
#1
|
|||
|
|||
|
Built-in exceptions buggy?
Hi. When I type the following code from Guido's tutorial section on exception handling into the interactive window, it works as expects. It says "oops..." if I give input a nonnumeric entry.
Quote:
However, if I save it in a module and run it, the error is considered unhandled. I get the following output: >>> Unhandled exception while debugging... Traceback (most recent call last): File "C:\Documents and Settings\lgtateos.wt\My Documents\GIS_curriculum\assignments\fileio\test_dir\cormorant\Script1.py", line 2, in ? x = int(raw_input("Please enter a number: ")) ValueError: invalid literal for int(): ddd >>> Oops! That was no valid number. Try again... I found someone saying something about a similar problem on another forum. They said this happened to them in Windows, but not Unix. I've tried a couple other built-in exceptions and they give the same problem. Is this a known bug? Is there a work around? Help! I don't want to get the reputation of not being able to handle things. Auguri. |
|
#2
|
|||
|
|||
|
What do you mean by "run it"?
1) Run the file e.g. python filename.py 2) import it in the interactive shell 3) execute it in the debugger 4) something else The example you gave had >>> in it, which suggests you are doing (2), but it also says "Unhandled exception while debugging" which suggests (3). Dave |
|
#3
|
|||
|
|||
|
Argh
Quote:
Hi Dave, I'm running it as a saved module in Pythonwin. At first I was using scenario #1. Then I tried running it in the debugger (#3). Both were giving an "unhandled exception" message. Don't know if you're at all familiar with Pythonwin, but when modules are run in Pythonwin, errors are reported in the Interactive Window. That's where I copied the exception with the >>> from. Hmmm .... bad news. I just tried it again using method #1 and it worked properly. I can't recreate it just now. I am sorry to say that I sometimes find Pythonwin to be buggy like this. Sometimes I have to restart it when it gets in a muddle. But on the day I was having this problem, I did try restarting it and still got the same results. Maybe a complete system restart did the trick. Argh. Well, I guess you can't help me if I can't recreate the problem! It just concerns me that I may not be able to rely on try/except! |
|
#4
|
|||
|
|||
|
Is there any reason in particular you are using activepython/pythonwin? Having never tried it myself I cant really comment but everything I've found with a quick google seems to be telling me it(the IDE, not necessarily ActivePython) kinda sucks.
I've been using python for some time now and have never come across an issue like this before having used several very different IDEs (IDLE, Eric, PyCrust, BoaConstructor, Eclipse, etc.) and have found try/except perfectly reliable. |
|
#5
|
|||
|
|||
|
Quote:
Hi c, When I started, I really only considered PythonWin and IDLE. At the time when I was deciding, IDLE did not seem to allow me to input command line arguments into a script. I posted a query about it on DevShed and so no one replied. http://forums.devshed.com/python-programming-11/passing-script-arguments-with-idle-478952.html?p=1906734#post1906734 Has this been changed? I think I read somewhere that it has... but I still don't know how to do it. Also, debugging seemed much less intuitive in IDLE, though I didn't spend a lot of time trying to learn it. Furthermore, you can learn the basics of PythonWin quickly, even if you don't have a programming background. I was looking for something I could share with the non-programming masses without wasting time explaining how to use the IDE. These people just want to write some basic work-flow enhancing scripts. Which one do you prefer, c-twofiveoh1? |
|
#6
|
|||
|
|||
|
Well there really isn't a lot to explain about IDLE, you have an interactive shell window where you can run scripts or program exerts, you open modules in text editor windows and type.
And whats wrong with setting sys.argv from the shell before running programs? From the IDLE docs; "With the ability to incrementally develop your programs and to quickly test code segments in the Shell Window you may find your self making less use of a symbolic debugger than you may be used to when working in other languages." It's true, I have personally never needed to use the debugging features of IDLE, although from what I gather you may be right they don't seem particularly intuitive, however if you are worried about accessibility to non-programmers, debuggers generally aren't the way to go, you would be better off imo taking the time to explain how tracebacks work and using them to solve errors. |
|
#7
|
|||
|
|||
|
Hey c, you forgot to tell me which one you prefer?
How about Quote:
So are you suggesting I type in... >>> sys.argv[1] = "bla" >>> sys.argv[2] = " other stuff" >>> # and so forth ...in the shell if these are my args? Ha. I never thought about that. Sure that would work! I was stuck in a GUI paradigm. Wonder why no one ever answered my post on that? I have found that knowing just a bit about the debugger is very useful for them. Stepping through code is a good way to learn what it's doing. Tracebacks are intimidating to non-programmers. They mostly just need to step through and see why they're not getting out of their loops or why their variable isn't what they expect it to be. They can learn what they need to know about the debugger in one quick lesson. Breakpoints, watches, how to step in/out/over, that's about it. These things are probably similarly easy in the other IDE's that you mentioned, but the only things installed on their machines is Pythonwin and IDLE. If I hear a strong enough argument for one of the others, I may look into it and see if I can get it installed on their lab machines where I have no admin, so have to go through some channels to do it. Probably I should be using another IDE for my own personal usage (and sanity), but I truly need to test everything I'm going to ask them to do in the same environment where they're going to be trying it. So I'll have to do some of both. |
|
#8
|
|||
|
|||
|
The answer to which one I prefer is: It depends. At the moment I'm currently working on my honours project for uni, and I'm currently using the Pydev IDE built on the Eclipse platform, because I need to be able to keep track of a lot of files easily also use subversion version control to keep track of my revisions.
I would have said that(eclipse), boaconstructor and Eric, seem to complex for what you need at the moment, all 3 are very intimidating, even to a competent programmer (and in my opinion both Eric and BoaConstructor arent the best designed IDEs arround) You could have a look at the wxPython IDEs though, there are a few of them. Mostly their just examples of how different wxWidgets can be used within python, but PyAlaMode might be worth a look for you, it combines (almost) everything you are looking for; an interactive shell, a multi-tab file editor, the only thing missing is a debugger. Its perfectly ok to put your sys.argv arguments into the shell before script execution like that. Just remember to do it before you run any code that needs them heh. If you are looking for something to test your stuff on before you give it to the students I would recommend Eclipse. The PyDev (python extensions) have to be downloaded as a separate package however (at lest last time I looked). You can find it here: http://pydev.sourceforge.net/ |
![]() |
| Viewing: Dev Shed Forums > Programming Languages > Python Programming > Built-in exceptions buggy? |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
|
|
|