If I double-click a Python script (or use the start command in the dos
prompt) a new dos prompt window is opened and my program is run. The
window goes away when the program is done. However, the window _also_
goes away when the program raises an exception, making it virtually
impossible to actually _see_ the exception... Is there a way to keep the
dos prompt window in this case?
A py2exe-fied version of the program shows the same behavior, which
leads my users to report problems like "the output file is mysteriously
truncated" instead of "I'm getting a traceback. Here, have a look."...
Any suggestions?
This is with Python 2.2.1 on Windows 98, but a report like above came
also froma WinXP user.
Just
For py2exe-packages apps you should redirect sys.stdout and sys.stderr
into a log-file.
Thomas
Thanks for both suggestions. Another workaround just occured to me: do a
raw_input("type enter to exit") in an exception hook. That should work
just fine in a py2exe-fied app as well I suppose.
Just
python -i
will allow you to enter interactive statements after your execution
finishes, which can be useful when you're debugging.
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Previous .sig file retired to www.homeforoldsigs.com
-----------------------------------------------------------------------
> "Just" <ju...@xs4all.nl> wrote in message
> news:just-F18BA3.1...@news1.xs4all.nl...
> [ how top see messages ]
> >
> > Thanks for both suggestions. Another workaround just occured to me: do a
> > raw_input("type enter to exit") in an exception hook. That should work
> > just fine in a py2exe-fied app as well I suppose.
> >
>
> python -i
>
> will allow you to enter interactive statements after your execution
> finishes, which can be useful when you're debugging.
Actually, debugging on my side is not really the problem (I usually
start the app from the command line anyway, it's a simple
platform-neutral command line tool), but it's end users: they want to
drop files onto the app. The DOS window can go away if everything went
ok (it only displays some progress info), but not if an exception
occurred: I want them to a) be able to tell something's wrong, and b)
tell me _what_ went wrong ;-). The raw_input() call upon exception seems
the easiest workaround for now.
Just
Try something like the following... We've had much success with
automatically emailing the traceback back to the developer using the
cgitb module -- you can never trust users to give you good error reports
<wink> besides the cgitb module provides much more context than the
standard exceptions... Let me know if you'd like the code...
try:
your code here
except:
import msvcrt, traceback
traceback.print_exc()
print 'Hit a key to exit'
while not msvcrt.kbhit():
pass
-- bjorn
[Bjorn Pettersen]
> Try something like the following... We've had much success with
> automatically emailing the traceback back to the developer using the
> cgitb module -- you can never trust users to give you good error reports
> <wink> besides the cgitb module provides much more context than the
> standard exceptions... Let me know if you'd like the code...
>
> try:
> your code here
> except:
> import msvcrt, traceback
> traceback.print exc()
> print 'Hit a key to exit'
> while not msvcrt.kbhit():
> pass
Ah, that looks like a good trick, I will try that.
Thanks for your code offer, but in most cases I will have to ask for the
input data anyway, so a simple traceback is good enough for now.
Just
cmd /K python myscript.py <args>
You could also add this to the cmd shortcut itself if you have one, but that
generally turns out to be a major pain since all dos-window based apps will
then leave their windows open.
A nice aspect of using a custom cmd shortcut is that you can set colors and
fonts and window size just for this app which might help distinguish it if
you have a lot of dos windows open. You can set the screen buffer height to
a high number so you can scroll really far back (not a good idea to make the
screen buffer width greater then the window width though).
you can type 'help cmd' in a dos window for more info on cmd switches.
HTH,
David LeBlanc
Seattle, WA USA
> --
> http://mail.python.org/mailman/listinfo/python-list
>cmd.exe will accept a flag telling it to stay open after something is run.
>You can create a shortcut along the lines of:
>
>cmd /K python myscript.py <args>
You may want to specify full paths, depending on where things are etc.
You can also do _several_ things in the cmd /k line by using "&". E.g., the following
%SystemRoot%\system32\cmd.exe /x /k prompt [$T$H$H$H$H$H$H] $P$G & title MyPy & D:\Python22\python.exe
will
- start a new cmd window
- set the prompt for it so it will show current time and directory, e.g.,
[17:19] C:\pywk>
- set the title of the window to MyPy
- start interactive python
the shortcut also lets you set the working directory. If you have a place you like
to test code, note that by setting the working directory there, everything will be
visible to import, aside from any other startup initialization. Thus you can separate
things by people or project or whatever. When you exit Python, you'll be at a cmd
prompt as specified, and in the working directory specified. Handy.
Don't forget that you can also change the icon associated with whatever you run via
the shortcut. I use the swiss army knife for many of my various "DOS" console shorcuts.
>
>You could also add this to the cmd shortcut itself if you have one, but that
>generally turns out to be a major pain since all dos-window based apps will
>then leave their windows open.
You mean the file extension association for .bat and .cmd? Yes, that doesn't work out
as a good general thing.
>
>A nice aspect of using a custom cmd shortcut is that you can set colors and
>fonts and window size just for this app which might help distinguish it if
>you have a lot of dos windows open. You can set the screen buffer height to
>a high number so you can scroll really far back (not a good idea to make the
>screen buffer width greater then the window width though).
>
A nice thing is that you can change things just for your current session,
using the properties selection from the system (left click title bar icon for it) menu.
>you can type 'help cmd' in a dos window for more info on cmd switches.
>
>HTH,
>
>David LeBlanc
>Seattle, WA USA
>
>> -----Original Message-----
[...] ;-)
Regards,
Bengt Richter
Although, unfortunately for the OP who has users on Win98, cmd.exe does
not exist except in NT/2K/XP.
-Peter
Not only that, but I want to only keep the window open when an exception
occurred.
But thanks for all the input!
Just
Just, maybe your users would be happy to enable an option
that would just *mail* you the exception traceback when
a problem occurs, rather than having to read it in an
ugly DOS window and perhaps make mistakes in transcribing
it when they tell you about it.
There was at least one recent thread which showed examples
of how to do this. If you can't dig them up (might be
in the Cookbook too) ask and someone can find a link or
repost.
If these are internal users, that is certainly a better
option than just printing the traceback.
-Peter
try:
something()
except:
print "Program encountered an error:"
print sys.exc_type
print sys.exc_value
os.system("pause")
-Ruben
Peter Hansen <pe...@engcorp.com> wrote in message news:<3d7d...@news.sentex.net>...
> Sorry if this is a Windows FAQ, I'm a newbie to Windows, but not to
> Python.
>
> If I double-click a Python script (or use the start command in the dos
> prompt) a new dos prompt window is opened and my program is run. The
> window goes away when the program is done. However, the window _also_
> goes away when the program raises an exception, making it virtually
> impossible to actually _see_ the exception... Is there a way to keep the
> dos prompt window in this case?
import sys, traceback
try:
do_something_here()
except:
# show the error
traceback.print_exc(file=sys.stderr)
# save the error
try:
import time
fp = open("my_error_log.txt", "a")
fp.write("\n%s\n" % time.ctime(time.time())
traceback.print_exc(file=fp)
fp.close()
except:
pass
# email the error
try:
import smtplib, StringIO
fp = StringIO.StringIO()
traceback.print_exc(file=fp)
conn = smtplib.SMTP("my.email.server.com")
conn.sendmail("m...@my.email.server.com",
[ "m...@my.email.server.com" ], fp.getvalue())
conn.quit()
fp.close()
except:
pass
# hold the screen
sys.stderr.write("\nPress ENTER to Continue: ")
sys.stdin.readline()
A couple of notes:
I import traceback at the very top, to prevent any possibility
that it can't be imported later.
I don't import smtplib or time at the top (unless I need them
anyway) since I won't (hopefully) need them all the time.
You mustn't screw with sys.stdin or sys.stderr if you expect
this to work (yes, you could use msvcrt.getch() on Windows,
which is where you said you are, but I like cross-platform
code).
Code above is untested, but I use similar code in many of my
programs; any error is most likely a typo.
Standard disclaimers apply.
Chris Gonnerman -- chris.g...@newcenturycomputers.net
http://newcenturycomputers.net