Mailman 3 Search results for "try except" - Python-ideas

Re: except-try block

by Steven D'Aprano

On Sun, Oct 11, 2020 at 01:04:46PM -0400, Wes Turner wrote: > (I must have missed the 'try' suffix) Indeed. And this is, in my opinion, a major problem with the suggestion. It obfuscates the code, hiding the fact that a new try block has been started. To be fair to the proposal, it does save a line and an indent level; saving lines is not much gain, since lines are cheap, but saving an indent is a small gain, since horizontal space is at a premium. So the proposal does have a small gain. A very small one. But the cost is to decrease readability and increase the likelihood of misreading the code, as Wes did. The analogy with `elif` is not a good one. `elif` is a distinct keyword, and it is at the start of the line: if condition elif condition whereas this proposal for an "excepttry" cuts the keyword in half, sticking a condition (the exception to catch) in between: try: ... except Exception try: We don't spell `elif` like this: if condition: else condition if: but that's what this proposal suggests for "excepttry". Another problem is the potential ambiguity: # Version 1 try: ... except A: try: ... except B: ... except C: ... # Version 2 try: ... except A: try: ... except B: ... except C: ... Using the proposed syntax, both of these would be written as: try: ... except A try: ... except B: ... except C: ... with no way of telling whether the "except B" goes with the outer try or the inner try. -- Steve

4 years, 5 months

Re: [Python-ideas] One-line "try with" statement

by Bruce Leban

On Sat, Mar 2, 2013 at 2:45 PM, Alan Johnson <alan(a)breakrs.com> wrote: > > try with context_manager(): > … bunch of code … > except: > … exception handler … This optimization saves a colon and some white space and mixes two unrelated concepts. The try/except pattern I want to optimize is try: x = expr1 except ValueError: x = expr2 For example: expr1 except ValueError else expr2 or try expr1 except ValueError else expr2 This is particularly useful in cases like this: a = ((try t.x except AttributeError else 0) + (try t.y except AttributeError else 0) + (try t.z except AttributeError else 0)) where standard try/except requires 13 lines and is much harder to read. Yes, this can be done with a function and two lambdas (and I've done it this way): try_except(lambda: expr1, ValueError, lambda: expr2) def try_except(value, exceptions, otherwise): try: return value() except exceptions or Exception: return otherwise() --- Bruce Learn how hackers think: http://j.mp/gruyere-security

12 years

Re: [Python-ideas] except expression

by Nathan Schneider

On Thu, Feb 13, 2014 at 1:47 PM, spir <denis.spir(a)gmail.com> wrote: > On 02/13/2014 07:43 PM, Amber Yust wrote: > >> Actually. What if we just reused 'try'? >> >> foo = bar() except BazException try 'qux' >> >> This also leads naturally to chaining multiple possible fallbacks: >> >> foo = bar() except BarException try baz() except BazException try >> None >> > > I like it. Especially because 'try' already works with 'except'. (But note > that 'try', like my proposal of 'then', normally introduces a block). > > This strikes me as counterintuitive because it is inconsistent: 'bar()' is being tried, but does not follow 'try', while the others do. And then the 'try None' has no corresponding 'except'. Suggestion: an expression like foo = (try bar() except BarException) that defaults to None if the exception is caught. This could then be chained with 'or': foo = (try bar() except BarException) or (try baz() except BazException) as distinguished from foo = (try bar() except BarException) or baz() which does not do any exception handling for baz(). (Apologies if something like this has been proposed above; I could not find it from skimming the thread.) Nathan > > d > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >

11 years

Let try-except check the exception instance

by Danilo J. S. Bellini

Hi! I was working on handling some exceptions from external software (e.g. database constraint triggers) switching the handler based on the messages that had been sent. Today we can do something like (running on Python 3.6.5): >>> try: ... # [...] ... session.commit() # Here it raises! ... # [...] ... except DatabaseError as exc: ... msg = get_db_error_msg_from_exception(exc) ... if msg == "beyond_limit": ... # [...] ... elif msg == "no_funds": ... # [...] ... else: ... raise That works, but I'd like to do something like: >>> try: ... # [...] ... except BeyondLimit: ... # [...] ... except NoFunds: ... # [...] Creating classes to "match" the exception in their __instancecheck__. Well, I tried to do so. A simplified example would be: >>> class MsgCheckerMeta(type): ... def __instancecheck__(cls, instance): ... return str(instance) == cls.internal ... >>> class ExceptionHasMessage(Exception, metaclass=MsgCheckerMeta): ... internal = "message" Using these new classes, we would get this: >>> try: ... raise Exception("message") ... except ExceptionHasMessage: ... print("Yeah!") ... Traceback (most recent call last): File "<stdin>", line 2, in <module> Exception: message Yet, >>> isinstance(Exception("message"), ExceptionHasMessage) True >>> try: ... raise Exception("message") ... except Exception as exc: ... print(isinstance(exc, ExceptionHasMessage)) ... True The idea is to allow catching exceptions beyond checking their MRO, using a class that checks the exception instance by implementing a custom __instancecheck__. -- Danilo J. S. Bellini --------------- "*It is not our business to set up prohibitions, but to arrive at conventions.*" (R. Carnap)

6 years, 9 months

Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

by Steven D'Aprano

On Tue, Jun 15, 2021 at 09:48:48PM -0300, Soni L. wrote: > def foo(): > try: return thing() > except ValueError: > try: return otherthing() > except ValueError: > try: return yetotherthing() > except ValueError: > if shouldraise(): raise > > Look at all that unnecessary indentation! Would be nice to get rid of it. It would be nice to use better looking four-space indents with indented blocks: def foo(): try: return thing() except ValueError: try: return otherthing() except ValueError: try: return yetotherthing() except ValueError: if shouldraise(): raise That makes the block structure of the code more clear, it reflects the semantics of the code better, it is much easier to modify (if we add an extra line between one of the try keywords and the returns, we don't need to change any existing lines, we just insert a new one: smaller diffs and better diffs). And it makes it more obvious that there is no final return (perhaps we forgot to add it?) and that the interpreter will automatically return None when we fall off the end of the function. But if none of those arguments convince you that ideomatic Python code is better Python code, that's okay too. You can remove almost all the indentation: def foo(): try: return thing() except ValueError: pass try: return otherthing() except ValueError: pass try: return yetotherthing() except ValueError: if shouldraise(): raise -- Steve

3 years, 8 months

Re: [Python-ideas] chained try (was Re: "maybe import"?)

by Bruce Leban

On Sat, Dec 28, 2013 at 12:05 PM, Andrew Barnert <abarnert(a)yahoo.com> wrote: > Would there be a use for a sequence like this without except on the end > (so if they all fail, it just raises)? > I think what you're talking about is just leaving the try off the last clause (as in the example below). > Can you put an exception type or tuple between the "except try"? What > about an as clause (so the block could use it)? > I started writing a mail with exactly this subject line and discarded it because of the latter two issues. In code I've recently written I have a chain of three and while the indentation is ugly, it's not so ugly that it cries out as a must fix language feature. And the problem is that I really want to limit to specific exceptions. In one case I have something like this: try: .... except KeyError: try: .... except AttributeError: try: .... except IndexError: .... and if I can't specify the specific exception, this is not helpful. On the other hand try: .... except KeyError try: .... except AttributeError try: .... except IndexError: .... only really saves me two colons and some whitespace. If the language had this feature, I'd use it, but that doesn't make it worth adding. --- Bruce

11 years, 2 months

Re: except-try block

by Wes Turner

(I must have missed the 'try' suffix) On Sun, Oct 11, 2020, 1:04 PM Wes Turner <wes.turner(a)gmail.com> wrote: > Nested exceptions indicated by a 'try' suffix added to the exception > expression > > How could these (else-if and nested conditional) syntaxes be combined? > > On Sun, Oct 11, 2020, 12:46 PM David Mertz <mertz(a)gnosis.cx> wrote: > >> I'm not advocating for it (nor against it). But the OP proposes something >> clear different from the example in current Python. >> >> On Sun, Oct 11, 2020, 12:39 PM Wes Turner >> >>> try: >>> f = open('myfile.txt') >>> s = f.readline() >>> i = int(s.strip()) >>> except OSError as err: >>> print("OS error: {0}".format(err)) >>> except ValueError: >>> print("Could not convert data to an integer.") >>> except: >>> print("Unexpected error:", sys.exc_info()[0]) >>> raise >>> ``` >>> >> >> I.e. >> >> try: >> might_raise_OSError() >> except OSError as err try: >> might_raise_ValueError() >> except ValueError try: >> might_raise_other() >> except: >> oh_well() >> >> The proposal is to more concisely catch exceptions raised within the >> 'except' suites themselves. >> >

4 years, 5 months

for ... except, with ... except

by Serhiy Storchaka

Python allows you to write code in tight and readable form. Consider the following example. with connect() as stream: # connect() or __enter__() can fail. for data in stream: # __next__() can fail write(data) # write() can fail The problem is that different lines can raise an exception of the same type (for example OSError). We want to catch and handle exceptions raised when open a connection, when read a data and when write a data in different ways. Currently you need to expand so convenient Python statements "with" and "for" (see PEP 343) _mgr = connect() _enter = type(_mgr).__enter__ _exit = type(_mgr).__exit__ _value = _enter(_mgr) _exc = True try: stream = _value _it = iter(stream) while True: try: data = next(_it) except StopIteration: break write(data) except: _exc = False if not _exit(_mgr, *sys.exc_info()): raise finally: if _exc: _exit(_mgr, None, None, None) and then add "try ... except" around corresponding explicit calls of `__enter__()` and `next()`. try: _mgr = connect() _enter = type(_mgr).__enter__ _exit = type(_mgr).__exit__ _value = _enter(_mgr) _exc = True except OSError: handle_connection_error() else: try: stream = _value try: _it = iter(stream) except OSError: handle_read_error() else: while True: try: data = next(_it) except StopIteration: break except OSError: handle_read_error() break try: write(data) except OSError: handle_write_error() except: _exc = False if not _exit(_mgr, *sys.exc_info()): raise finally: if _exc: _exit(_mgr, None, None, None) Does not it look ugly? I propose to add "except" clause to "for" and "with" statement to catch exceptions in the code that can't be wrapped with "try ... except". for VAR in EXPR: BLOCK except EXC: HANDLER should be equivalent to try: _it = iter(EXPR) except EXC: HANDLER else: while True: try: VAR = next(_it) except StopIteration: break except EXC: HANDLER break BLOCK and with EXPR as VAR: BLOCK except EXC: HANDLER try: _mgr = EXPR _enter = type(_mgr).__enter__ _exit = type(_mgr).__exit__ _value = _enter(_mgr) _exc = True except EXC: HANDLER else: try: VAR = _value BLOCK except: _exc = False if not _exit(_mgr, *sys.exc_info()): raise finally: if _exc: _exit(_mgr, None, None, None) And correspondingly for asynchronous versions "async for" and "async with". So you will be able to add errors handling like in: with connect() as stream: for data in stream: try: write(data) except OSError: handle_write_error() except OSError: handle_read_error() except OSError: handle_connection_error()

5 years, 7 months

Re: except-try block

by Wes Turner

How is this different from the existing exception handling? From https://docs.python.org/3/tutorial/errors.html#exceptions : > The last except clause may omit the exception name(s), to serve as a wildcard. Use this with extreme caution, since it is easy to mask a real programming error in this way! It can also be used to print an error message and then re-raise the exception (allowing a caller to handle the exception as well): ```python import sys try: f = open('myfile.txt') s = f.readline() i = int(s.strip()) except OSError as err: print("OS error: {0}".format(err)) except ValueError: print("Could not convert data to an integer.") except: print("Unexpected error:", sys.exc_info()[0]) raise ``` https://docs.python.org/3/library/exceptions.html https://docs.python.org/3/c-api/exceptions.html On Sun, Oct 11, 2020, 12:25 PM haael <haael(a)interia.pl> wrote: > > Very often I use the following construction (especially in operators): > > try: > something > except SomeError: > try: > something_else > except AnotherError: > try: > something_completely_different > except Whatever: > return NotImplemented > > > I propose a construction to simplify the staircase hierarchy of > exception handlers: > > try: > something > except SomeError try: > something_else > except AnotherError try: > something_completely_different > except Whatever: > return NotImplemented > > This would be somewhat analogous to `else if` blocks. > > This pattern is very common in operator implementations. And this > proposal could simplify it a bit. > > haael > _______________________________________________ > Python-ideas mailing list -- python-ideas(a)python.org > To unsubscribe send an email to python-ideas-leave(a)python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/XNR5P… > Code of Conduct: http://python.org/psf/codeofconduct/ >

4 years, 5 months

Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

by Chris Angelico

On Wed, Jun 16, 2021 at 10:51 AM Soni L. <fakedme+py(a)gmail.com> wrote: > > Sometimes it would be useful to be able to write: > > def foo(): > try: return thing() > except ValueError; > try: return otherthing() > except ValueError; > try: return yetotherthing() > except ValueError; > if shouldraise(): raise > > But currently this needs to be written like so: > > def foo(): > try: return thing() > except ValueError: > try: return otherthing() > except ValueError: > try: return yetotherthing() > except ValueError: > if shouldraise(): raise > > Look at all that unnecessary indentation! Would be nice to get rid of it. Dangerous idea - my first interpretation of that syntax was that it would be equivalent to "except ValueError: pass", which would be very confusing (it's subtly different in your example with return, and drastically different in other cases). Are you doing this sort of thing a lot? And if you are, do you actually need/want the exception chaining that comes from burying more and more code into the except clauses? I know this is just a trivial example, but I'd be looking to see if it can be done with a loop instead. def foo(): for func in (thing, otherthing, yetotherthing): try: return func() except ValueError: pass or something like that. ChrisA

3 years, 8 months

Python-ideas search results for query "try except"