On Thu, 31 May 2018 14:00:24 -0400
Alexander Belopolsky
wrote:
>
> Is this really true? Consider the following simple code
>
> class E(Exception):
> def __init__(self):
> print("instantiated")
>
> try:
> raise E
> except E:
> pass
>
> Is it truly necessary to instantiate
On Thu, May 31, 2018 at 10:37 AM Nick Coghlan wrote:
>
> The exception machinery deliberately attempts to avoid instantiating
exception objects whenever it can, but that gets significantly more
difficult if we always need to create the instance before we can decide
whether or not the raised
On Wed, May 30, 2018 at 10:47 PM, Danilo J. S. Bellini
wrote:
try:
> ... # [...]
> ... session.commit() # Here it raises!
> ... # [...]
> ... except DatabaseError as exc:
> ... msg = get_db_error_msg_from_exception(exc)
> ... if msg == "beyond_limit":
> ... #
On 31 May 2018 at 14:47, Danilo J. S. Bellini
wrote:
> The idea is to allow catching exceptions beyond checking their MRO,
> using a class that checks the exception instance by implementing
> a custom __instancecheck__.
>
The exception machinery deliberately attempts to avoid instantiating
In one of my own packages, I use the following to catch dynamic error
messages:
def handle_error(exc):
# do stuff with exc
with catch('error_code', handle_error):
# do stuff that can raise an error
The definition of "catch" is as follows, assuming the root exception
On 31 May 2018 at 02:41, Steven D'Aprano wrote:
> Since error messages are rarely part of the exception API, testing for
> them is fragile and prone to errors. For example, what if the message
> changes to "no money" or "out of funds" or "insufficient funds" or
> "keine Mittel"? Since the error
Current documentation says:
"An object is compatible with an exception if it is the class or a base
class of the exception object or a tuple containing an item compatible with
the exception."
https://docs.python.org/3/reference/compound_stmts.html#the-try-statement
It is, in my opinion, not
On 5/31/2018 12:47 AM, Danilo J. S. Bellini wrote:
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:
... #
Would guards (such as from the switch-case discussions) be a good fit?
try:
...
except RuntimeError as e if e.message == "tie":
...
On Thu, May 31, 2018, 00:48 Danilo J. S. Bellini
wrote:
> Hi!
> I was working on handling some exceptions from external software
> (e.g. database
On Thu, May 31, 2018 at 01:47:17AM -0300, Danilo J. S. Bellini wrote:
> >>> try:
> ... # [...]
> ... session.commit() # Here it raises!
> ... # [...]
> ... except DatabaseError as exc:
> ... msg = get_db_error_msg_from_exception(exc)
> ... if msg == "beyond_limit":
> ...
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!
11 matches
Mail list logo
