Re: Error handling in context managers

On Jan 16, 2017, at 11:34 PM, Peter Otten <__pete...@web.de> wrote: > > Gregory Ewing wrote: > >> Israel Brewster wrote: >>> The problem is that, from time to time, I can't get a connection, the >>> result being that cursor is None, >> >> That's your problem right there -- you want a better-beha

Re: Error handling in context managers

On Jan 16, 2017, at 8:01 PM, Gregory Ewing wrote: > > Israel Brewster wrote: >> The problem is that, from time to time, I can't get a connection, the result >> being that cursor is None, > > That's your problem right there -- you want a better-behaved > version of psql_cursor(). > > def get_psq

Re: Error handling in context managers

On Jan 16, 2017, at 1:27 PM, Terry Reedy wrote: > > On 1/16/2017 1:06 PM, Israel Brewster wrote: >> I generally use context managers for my SQL database connections, so I can >> just write code like: >> >> with psql_cursor() as cursor: >> >> >> And the context manager takes care of making

Re: Error handling in context managers

Gregory Ewing wrote: > Israel Brewster wrote: >> The problem is that, from time to time, I can't get a connection, the >> result being that cursor is None, > > That's your problem right there -- you want a better-behaved > version of psql_cursor(). > > def get_psql_cursor(): > c = psql_curso

Re: Error handling in context managers

Terry Reedy wrote: Traceback (most recent call last): File "", line 1, in with None: pass AttributeError: __enter__ Like he said, you get an AttributeError! -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Error handling in context managers

Israel Brewster wrote: The problem is that, from time to time, I can't get a connection, the result being that cursor is None, That's your problem right there -- you want a better-behaved version of psql_cursor(). def get_psql_cursor(): c = psql_cursor() if c is None: raise CantGet

Re: Error handling in context managers

On 1/16/2017 1:06 PM, Israel Brewster wrote: I generally use context managers for my SQL database connections, so I can just write code like: with psql_cursor() as cursor: And the context manager takes care of making a connection (or getting a connection from a pool, more likely), and cl

Re: Error handling in context managers

Steve D'Aprano : > or you can let the context manager do what it does, and write your own code > to do what you do: > > try: > with ...: >... > except: > ... Even better: try: a = open(...) except ...: ... with a: ... You want to catch exceptions

Re: Error handling in context managers

On Tue, 17 Jan 2017 05:06 am, Israel Brewster wrote: > I generally use context managers for my SQL database connections, so I can > just write code like: > > with psql_cursor() as cursor: > > > And the context manager takes care of making a connection (or getting a > connection from a pool,

Re: Error handling in context managers

Israel Brewster wrote: > I generally use context managers for my SQL database connections, so I can > just write code like: > > with psql_cursor() as cursor: > > > And the context manager takes care of making a connection (or getting a > connection from a pool, more likely), and cleaning up

Re: Error handling in context managers

On Tue, Jan 17, 2017 at 5:06 AM, Israel Brewster wrote: > I generally use context managers for my SQL database connections, so I can > just write code like: > > with psql_cursor() as cursor: > > > And the context manager takes care of making a connection (or getting a > connection from a po

Re: Error handling with @parallel decorator

Thanks a lot Steven for your reply. I got the issue, it was my own FabricException class, when I started using Exception then I could catch the exception successfully and then I got the type of exception as well by using your suggested type(err). Your code snippet did help me to find the issue soon

Re: Error handling with @parallel decorator

On Monday 18 January 2016 17:15, Ankur Agrawal wrote: > I am trying to catch Abort exception. When I use fabric's run(...) method, > the host it tries to connect is not available and so it aborts with > connect time out exception. I am not able to catch it. Following is a two > different ways of c

Re: error handling when opening files

> Interestingly, did you know that even *closing* a file can fail? No I didn't, interesting piece on information for sure! I thought close() is usually made to always succeed regardless if it actually hosed up. Any idea what the context manager will do in that case? (I ask as that else-with form l

Re: error handling when opening files

> If that's what you're expecting, then your message is wrong, because > you say "file never opened" - but you possibly DID open it, and maybe > read something from it. The choice between the two forms should be > based on whether you want to distinguish between errors on opening and > errors on re

Re: error handling when opening files

On Tue, Jul 8, 2014 at 7:00 PM, Steven D'Aprano wrote: > Interestingly, did you know that even *closing* a file can fail? I know that can happen with SSL sockets (which can require writing and reading). Can't think of any situations on normal file systems where that's true, unless the actual fail

Re: error handling when opening files

On Tue, 08 Jul 2014 01:49:58 +0200, Alex Burke wrote: > Hi there, > > While reading up on a previous thread 'open() and EOFError' I saw the > following (with minor changes to help make my question clearer) block > suggested as a canonical way to open files and do something: Emphasis on "a" canon

Re: error handling when opening files

Alex Burke : > While reading up on a previous thread 'open() and EOFError' I saw the > following (with minor changes to help make my question clearer) block > suggested as a canonical way to open files and do something: > > try: > f = open(path) > except IOError: > handle_error() > else: >

Re: error handling when opening files

On Tue, Jul 8, 2014 at 9:49 AM, Alex Burke wrote: > The reason I preferred the second was in addition to catching the > IOError when attempting the open() if the file does not exist I > thought I was accounting for the possibility en error occurs while > reading data out of the file. If that's wh

Re: Error handling in Python

[EMAIL PROTECTED] wrote: > Dear Members of the group, > If I open a url by urlopen in the urllib, the file is either opening a > file or if no url is there it would give error. The error is generated > can be handled by IOError handling schemes. > But if there are thousands or millions of URLs and

Re: Error handling in SAX

[EMAIL PROTECTED] wrote: > (this is a repost, for it's been a while since I posted this text via > Google Groups and it plain didn't appear on c.l.py - if it did appear > anyway, apols) It did, although some people have added google groups to their kill file. > So I set out to learn handling thr

Re: Error Handling

That worked. Thanks! Victor On Sun, Apr 20, 2008 at 11:02 PM, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > En Thu, 17 Apr 2008 16:19:12 -0300, Victor Subervi < > [EMAIL PROTECTED]> escribió: > > > try: > > cursor.execute(sql) > > print '¡Exito en introducir!' > > print 'Es

Re: Error Handling

En Thu, 17 Apr 2008 16:19:12 -0300, Victor Subervi <[EMAIL PROTECTED]> escribió: > try: > cursor.execute(sql) > print '¡Exito en introducir!' > print 'Esta página va a regresar a la página principal del carrito > de compras en 10 segundos.' > except IntegrityError: >

Re: Error handling in file generation (Pythonic way: with / decorators?)

In message <[EMAIL PROTECTED]>, xavim wrote: > This should read:: > > try: > (...) > except: > os.remove(dictpath) > raise Perhaps: try : (...) except : try : os.remove(dictpath) except : pass #end t

Re: Error handling in file generation (Pythonic way: with / decorators?)

On Wed, 29 Aug 2007 08:58:52 +, xavim wrote: > I am having some problems with how to do proper error handling. > One of the requirements is that the destination file should not be > created if there is any error in the processing. > > I have come out with the following code:: > > dictfil

Re: Error handling in file generation (Pythonic way: with / decorators?)

On Aug 29, 10:58 am, xavim <[EMAIL PROTECTED]> wrote: > (...) > try: > (...) > except: > os.remove(dictpath) This should read:: try: (...) except: os.remove(dictpath) raise Sorry. -- http://mail.python.org/mailman/listinfo/python-list

Re: Error handling. Python embedded into a C++ app.

Maybe of interest to people loking for a solution: I solved my issue by changing the program retroactively from a pure MFC app to a console one using this procedure: http://homepage3.nifty.com/ysflight/mfcconsole/mfcconsole.html I am still not sure why all of my other attempts failed, but most so

Re: Error handling. Python embedded into a C++ app.

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >You would use try: and then on the next line except: Thanks for the idea, but it did not help. I can not wrap every pythion line in python, so I wrote the following code on the C++ side: -- snip - try { i

Re: Error handling. Python embedded into a C++ app.

You would use try: and then on the next line except: I am not sure what the best answer is but you could write your errors to a file and then load them if all else fails. https://sourceforge.net/projects/dex-tracker Wolfram wrote: > I have a problem with displaying errors in an embedded situat

Re: error handling

On Thursday 12 October 2006 04:47, Gabriel Genellina wrote: > |Why not refer to the *current* documentation? Gabriel, Thank you, some time I (we) forget to look at the most obvious place ;) Meanwhile yesterday I found some useful info on the web, which an *except* statement needs a string object

Re: error handling

lol you are so right! I didn't even notice this was the 1.5.2 version! Gabriel Genellina wrote: > At Wednesday 11/10/2006 16:16, Bernard wrote: > > >I just found this webpage showing the most common exceptions: > >http://pydoc.org/1.5.2/exceptions.html > > Why not refer to the *current* documenta

Re: error handling

At Wednesday 11/10/2006 16:16, Bernard wrote: I just found this webpage showing the most common exceptions: http://pydoc.org/1.5.2/exceptions.html Why not refer to the *current* documentation? http://docs.python.org/lib/module-exceptions.html (You already have it installed with Python) 1.5.2

Re: error handling

I just found this webpage showing the most common exceptions: http://pydoc.org/1.5.2/exceptions.html I hope this can help in some way. Fulvio wrote: > *** > Your mail has been scanned by InterScan MSS. > *** > > > Hello there, > > Simple question : how do

Re: error handling

Hi Fulvio, I often use this try except to find out about what type of errors might happen in my code: I use it when I really don't know what might happen. try: # do something except: print "Unexpected error:", sys.exc_info()[0] continue once it catches an error, just take a good look

Re: error handling in user input: is this natural or just laborious

Lawrence D'Oliveiro wrote: > In message <[EMAIL PROTECTED]>, James Stroud > wrote: > > >>Patently. Tabs should be reserved for tables, for which tabs were named. >>If they were meant to be used for indenting, they would have been >>named "indenters". > Or possibly "inds", in a similarly abbrevi

Re: error handling in user input: is this natural or just laborious

In message <[EMAIL PROTECTED]>, sam wrote: > i'm still in the early stages, and am trying to code something simple > and interactive to get the percentages of the portfolio in the five > different investment categories. i thought i'd get in with the error > handling early so if someone types in so

Re: error handling in user input: is this natural or just laborious

In message <[EMAIL PROTECTED]>, James Stroud wrote: > Patently. Tabs should be reserved for tables, for which tabs were named. > If they were meant to be used for indenting, they would have been > named "indenters". Really? I thought they were for tabulators

Re: error handling in user input: is this natural or just laborious

a huge amount to think about there. special thanks to james for taking the time to make such detailed responses. the problem is that even though nested loops and the like place a heavy analytical burden on the programmer (i.e. me) as he tries to remember what does what, conceptualizing a program

Re: error handling in user input: is this natural or just laborious

sam a écrit : (snip) > i'm still in the early stages, and am trying to code something simple > and interactive to get the percentages of the portfolio in the five > different investment categories. i thought i'd get in with the error > handling early so if someone types in something wrong (like a

Re: error handling in user input: is this natural or just laborious

On Fri, 06 Oct 2006 17:19:01 -0700, sam wrote: > gosh, a lot of work to get some input. i must be missing something, > though this is a lot better than what i had before... Welcome to the real world of programming. Writing your algorithms is, generally, the easy part. Handling data input and outp

Re: error handling in user input: is this natural or just laborious

James Stroud wrote: > sam wrote: > >> this does what i want, though i don't like the inner while loop having >> to be there [snip] > A little cleaner. Now, lets tighten it up a bit more, and put nested > loops into functions. Im getting rid of keeping track of the running > total, that will clea

Re: error handling in user input: is this natural or just laborious

sam wrote: > this does what i want, though i don't like the inner while loop having > to be there > > > def get_pct(): > while True: > pct_list=[['cash', 0], ['bond', 0], ['blue', 0], ['tech', 0], > ['dev', > 0]] > total=0 > for i in range(len(pct_

Re: error handling in user input: is this natural or just laborious

this does what i want, though i don't like the inner while loop having to be there def get_pct(): while True: pct_list=[['cash', 0], ['bond', 0], ['blue', 0], ['tech', 0], ['dev', 0]] total=0 for i in range(len(pct_list)):

Re: error handling in user input: is this natural or just laborious

you're right, of course. it occurred to me that, even if it were manageable for a few items, it would quickly become absurd as the number of items grew. this: def get_pct(): while True: pct_list=[['cash', 0], ['bond', 0], ['blue', 0], ['tech', 0], ['dev', 0]]

Re: error handling in user input: is this natural or just laborious

James Stroud wrote: > sam wrote: > >> hi all, >> >> i'm starting to put together a program to simulate the performance of >> an investment portfolio in a monte carlo manner doing x thousand >> iterations and extracting data from the results. >> >> i'm still in the early stages, and am trying to co

Re: error handling in user input: is this natural or just laborious

sam wrote: > hi all, > > i'm starting to put together a program to simulate the performance of > an investment portfolio in a monte carlo manner doing x thousand > iterations and extracting data from the results. > > i'm still in the early stages, and am trying to code something simple > and inte

Re: error handling

Steven D'Aprano wrote: > That's broken. > > Imagine that somewhere in main() the following is called: > > D = {"a": "apple", "b": "bicycle", "c": "cat"} > print D["aardvark"] > > Your code now prints "That number is way too big!". That's not good. > > try...except blocks should, as a general r

Re: error handling

In article <[EMAIL PROTECTED]>, Chris <[EMAIL PROTECTED]> wrote: >I want to do this because there are several spots in my program where >an error might occur that I want to handle the same way, but I don't >want to rewrite the try..except block again. Is that clearer? .

Re: error handling

On Thu, 10 Aug 2006 16:59:56 -0700, Farshid Lashkari wrote: > Chris wrote: >> But sometimes you can have too many of these statements in your >> program, and it starts to get tangled and nasty looking. Is there a way >> I can modify sys.error so that when the interpreter comes accross an >> IndexE

Re: error handling

Chris wrote: > I want to handle errors for a program i'm building in a specific way, > but I don't want to use try/except/finally because it requires forming > new blocks of code. I want to be able things like this: > > a = [2, 423, "brownie", 234.34] > try: a[890] > except IndexError: # I don't u

Re: error handling

I want to do this because there are several spots in my program where an error might occur that I want to handle the same way, but I don't want to rewrite the try..except block again. Is that clearer? And I meant sys.stderr... sorry 'bout that Simon Forman wrote: > Chris wrote: > > I want to hand

Re: error handling

Chris wrote: > I want to handle errors for a program i'm building in a specific way, > but I don't want to use try/except/finally because it requires forming > new blocks of code. I want to be able things like this: > > a = [2, 423, "brownie", 234.34] > try: a[890] > except IndexError: # I don't us

Re: error handling

Chris wrote: > But sometimes you can have too many of these statements in your > program, and it starts to get tangled and nasty looking. Is there a way > I can modify sys.error so that when the interpreter comes accross an > IndexError it prints "That number is way too big!" before it exits? Hi,