Re: PEP 249 Compliant error handling

On 17Oct2017 21:38, Karsten Hilbert wrote: That's certainly a possibility, if that behavior conforms to the DB API "standards". My concern in this front is that in my experience working with other PEP 249 modules (specifically psycopg2), I'm pretty sure that columns designated as type VARCHAR

Re: PEP 249 Compliant error handling

On Wed, Oct 18, 2017 at 08:32:48AM -0800, Israel Brewster wrote: > actual question, which is "how does the STANDARD (PEP 249 in > this case) say to handle this, or, baring that (since the > standard probably doesn't explicitly say), how do the > MAJORITY of PEP 249 compliant modules handle this?"

Re: PEP 249 Compliant error handling

On 17/10/17 19:26, Israel Brewster wrote: > I have written and maintain a PEP 249 compliant (hopefully) DB API for the 4D > database, and I've run into a situation where corrupted string data from the > database can cause the module to error out. Specifically, when decoding the > string, I get a

Re: PEP 249 Compliant error handling

On Oct 17, 2017, at 12:02 PM, MRAB wrote: > > On 2017-10-17 20:25, Israel Brewster wrote: >> >>> On Oct 17, 2017, at 10:35 AM, MRAB >> > wrote: >>> >>> On 2017-10-17 18:26, Israel Brewster wrote: I have written and maintain a PEP 249 compliant (hopefully)

Re: PEP 249 Compliant error handling

> On Oct 18, 2017, at 1:46 AM, Abdur-Rahmaan Janhangeer > wrote: > > all corruption systematically ignored but data piece logged in for analysis Thanks. Can you expound a bit on what you mean by "data piece logged in" in this context? I'm not aware of any logging specifications in the PEP 24

Re: PEP 249 Compliant error handling

all corruption systematically ignored but data piece logged in for analysis Abdur-Rahmaan Janhangeer, Mauritius abdurrahmaanjanhangeer.wordpress.com On 17 Oct 2017 21:43, "Israel Brewster" wrote: > I have written and maintain a PEP 249 compliant (hopefully) DB API for the > 4D database, and I'v

Re: PEP 249 Compliant error handling

On 2017-10-17 20:25, Israel Brewster wrote: On Oct 17, 2017, at 10:35 AM, MRAB > wrote: On 2017-10-17 18:26, Israel Brewster wrote: I have written and maintain a PEP 249 compliant (hopefully) DB API for the 4D database, and I've run into a situation where co

Aw: Re: PEP 249 Compliant error handling

> That's certainly a possibility, if that behavior conforms to the DB API > "standards". My concern in this front is that in my experience working with > other PEP 249 modules (specifically psycopg2), I'm pretty sure that columns > designated as type VARCHAR or TEXT are returned as strings (unic

Re: PEP 249 Compliant error handling

> On Oct 17, 2017, at 10:35 AM, MRAB wrote: > > On 2017-10-17 18:26, Israel Brewster wrote: >> I have written and maintain a PEP 249 compliant (hopefully) DB API for the >> 4D database, and I've run into a situation where corrupted string data from >> the database can cause the module to error

Re: PEP 249 Compliant error handling

On 2017-10-17 18:26, Israel Brewster wrote: I have written and maintain a PEP 249 compliant (hopefully) DB API for the 4D database, and I've run into a situation where corrupted string data from the database can cause the module to error out. Specifically, when decoding the string, I get a "Uni

PEP 249 Compliant error handling

I have written and maintain a PEP 249 compliant (hopefully) DB API for the 4D database, and I've run into a situation where corrupted string data from the database can cause the module to error out. Specifically, when decoding the string, I get a "UnicodeDecodeError: 'utf-16-le' codec can't deco

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

Error handling in context managers

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 after the fact (such as putting the

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

Error handling with @parallel decorator

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 code snippet- First I try following - class FabricException(Ex

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

error handling when opening files

and if the with block succeeds set it to some other value thus being able to do an if not None check afterward. That's probably enough conflated questioning for now.. who'd have thought opening a file could be such a poser! Yep, it's always the error handling :) Thanks in advance,

error handling in multithreaded extension callbacks

Hi, In my extension I'm calling python functions as callbacks from a thread generated in an external module. This works very well, but I'm not sure about the error handling. 1. Normally the python interpreter exits if it runs on an unhandled error. Is this the preferred standard be

Req. for feedback -- writings on error handling & cleanup (Py3)

ple selection: no scary math here. Contents so far: 3 [chapter title, undecided]. 3.1 Error handling. 3.1.1 Error, failure, success (terminology). 3.1.2 The concept of exceptions. 3.1.3 Routine call hierarchies, call stack unwinding and stack traces. 3.1.4 Raising an exception / exception type

Re: Exception as the primary error handling mechanism?

Lie Ryan schreef: > On 1/7/2010 10:43 PM, Roel Schroeven wrote: >> - I tend to think that not following that practice trains me to be >> careful in all cases, whereas I'm afraid that following the practice >> will make me careless, which is dangerous in all the cases where the >> practice won't pro

Re: Exception as the primary error handling mechanism?

Lie Ryan wrote: That's a sign of a gotcha... a well-designed language makes you think about your problem at hand and less about the language's syntax. Not until you learn the language that is. From a Python newbee ;-) -- http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

On 1/7/2010 10:43 PM, Roel Schroeven wrote: - I tend to think that not following that practice trains me to be careful in all cases, whereas I'm afraid that following the practice will make me careless, which is dangerous in all the cases where the practice won't protect me. That's a sign of a

Re: Exception as the primary error handling mechanism?

Bruno Desthuilliers schreef: > Phlip a écrit : >> On Jan 5, 8:49 pm, Steven D'Aprano >> wrote: >> (A related question - why can't I just go 'if record = method(): use (record)'. Why extra lines just to trap and assign the variable before using it?) >>> Because that idiom is respons

Re: Exception as the primary error handling mechanism?

Steve Holden writes: > Brilliant. It takes a real whole human being to make an admission like > that (or even to bother to question their own behavior sufficiently to > bother re-reading the thread). I think a lot more of you for the > admission. Seconded. -- \ “bash awk grep perl sed,

Re: Exception as the primary error handling mechanism?

r0g wrote: > r0g wrote: >> Steven D'Aprano wrote: >>> On Wed, 06 Jan 2010 23:58:21 +, r0g wrote: >>> Steven D'Aprano wrote: > On Wed, 06 Jan 2010 22:46:33 +, r0g wrote: > >> Grant Edwards wrote: >>> On 2010-01-06, r0g wrote: See? Spoiling for an argument even now!

Re: Exception as the primary error handling mechanism?

r0g wrote: > Steven D'Aprano wrote: >> On Wed, 06 Jan 2010 23:58:21 +, r0g wrote: >> >>> Steven D'Aprano wrote: On Wed, 06 Jan 2010 22:46:33 +, r0g wrote: > Grant Edwards wrote: >> On 2010-01-06, r0g wrote: >>> See? Spoiling for an argument even now! I never said you were

Re: Exception as the primary error handling mechanism?

Steven D'Aprano wrote: > On Wed, 06 Jan 2010 23:58:21 +, r0g wrote: > >> Steven D'Aprano wrote: >>> On Wed, 06 Jan 2010 22:46:33 +, r0g wrote: >>> Grant Edwards wrote: > On 2010-01-06, r0g wrote: >> See? Spoiling for an argument even now! I never said you weren't allowed >> to bu

Re: Exception as the primary error handling mechanism?

On Wed, 06 Jan 2010 23:58:21 +, r0g wrote: > Steven D'Aprano wrote: >> On Wed, 06 Jan 2010 22:46:33 +, r0g wrote: >> >>> Grant Edwards wrote: On 2010-01-06, r0g wrote: > NO! It's a rude way to start a sentence don't you think? No. When somebody asks a yes/no question,

Re: Exception as the primary error handling mechanism?

Steven D'Aprano wrote: > On Wed, 06 Jan 2010 22:46:33 +, r0g wrote: > >> Grant Edwards wrote: >>> On 2010-01-06, r0g wrote: >>> NO! It's a rude way to start a sentence don't you think? >>> No. When somebody asks a yes/no question, answering yes or no seems >>> quite polite to me. Follo

Assertions, challenges, and polite discourse (was: Exception as the primary error handling mechanism?)

Grant Edwards writes: > Answering a yes/no question with "no" doesn't seem to me to be > combative if the correct answer is indeed "no". But I've lost > track of the post you found objectionable... In fairness, the “No” was in response, not to an explicit question, but to an assertion. Every a

Re: Exception as the primary error handling mechanism?

On Wed, 06 Jan 2010 22:46:33 +, r0g wrote: > Grant Edwards wrote: >> On 2010-01-06, r0g wrote: >> >>> NO! It's a rude way to start a sentence don't you think? >> >> No. When somebody asks a yes/no question, answering yes or no seems >> quite polite to me. Following the yes/no answer with

Re: Exception as the primary error handling mechanism?

Grant Edwards wrote: > On 2010-01-06, r0g wrote: > >> NO! It's a rude way to start a sentence don't you think? > > No. When somebody asks a yes/no question, answering yes or no > seems quite polite to me. Following the yes/no answer with an > explanation of the answer is always nice, and I've

Re: Exception as the primary error handling mechanism?

Ben Finney wrote: > r0g writes: > >> NO! It's a rude way to start a sentence don't you think? > > Shouting is usually rude, yes. > >> Just because you're correcting someone doesn't mean you have to be >> combative and try and make them feel small. > > Again, you're reading something that isn't

Re: Exception as the primary error handling mechanism?

to appreciate exceptions as a superior form of error handling. I simply stated that throwing an exception when none should be thrown is a pain and often inefficient on top of that. That's all, really. > I wouldn't say that's normal. If you don't care about the function'

Re: Exception as the primary error handling mechanism?

Phlip wrote: > On Jan 6, 10:23 am, Lie Ryan wrote: >> On 1/7/2010 3:41 AM, Phlip wrote: >> >>> Steve Holden wrote: y'all just keep defending the approach to programming that *you* think is best. >>> Speak for yourself... >> Everyone speaks for themselves, is that a problem? > > Of cours

Re: Exception as the primary error handling mechanism?

On Wed, 06 Jan 2010 12:39:36 -0800, Phlip wrote: > And now, if everyone will excuse me, I have to get back to writing a > unit-test-to-code ratio of 2:1. In my experience, that's about half as many unit-tests as needed for full code coverage for even a simple class. If you're trying to impress u

Re: Exception as the primary error handling mechanism?

On 1/6/2010 1:20 PM, Lie Ryan wrote: Python decided that the default behavior should be raising exception and sentinel have to use the dict.get() method. Simple and clear. The other possible behavior (i.e. slicing returns a sentinel while dict.get() raises an exception) is arguably just as simpl

Re: Exception as the primary error handling mechanism?

On Jan 6, 10:23 am, Lie Ryan wrote: > On 1/7/2010 3:41 AM, Phlip wrote: > > > Steve Holden wrote: > > >> y'all just keep defending the approach to programming that > >> *you* think is best. > > > Speak for yourself... > > Everyone speaks for themselves, is that a problem? Of course not. I was poi

Re: Exception as the primary error handling mechanism?

On 2010-01-06, Lie Ryan wrote: > On 1/7/2010 3:41 AM, Phlip wrote: >> Steve Holden wrote: >> >>> y'all just keep defending the approach to programming that >>> *you* think is best. >> >> Speak for yourself... > > Everyone speaks for themselves, [...] Except for the Lorax. He speaks for the trees

Re: Exception as the primary error handling mechanism?

On 1/7/2010 3:41 AM, Phlip wrote: Steve Holden wrote: y'all just keep defending the approach to programming that *you* think is best. Speak for yourself... Everyone speaks for themselves, is that a problem? -- http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

On 1/7/2010 2:12 AM, Phlip wrote: On Jan 5, 10:54 pm, Benjamin Kaplan wrote: {41: None}[41] ? In cases where None is a valid result, you can't use it to signal failure.. Asked and answered. You change the "sentinel" in .fetch to something else. I believe Ben Kaplan's point is that if dict

Re: Exception as the primary error handling mechanism?

Steve Holden wrote: y'all just keep defending the approach to programming that *you* think is best. Speak for yourself... -- http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

On 1/6/10 10:12 AM, Phlip wrote: On Jan 5, 10:54 pm, Benjamin Kaplan wrote: {41: None}[41] ? In cases where None is a valid result, you can't use it to signal failure. Asked and answered. You change the "sentinel" in .fetch to something else. When did I specify a sentinel value

Re: Exception as the primary error handling mechanism?

Phlip a écrit : On Jan 5, 8:49 pm, Steven D'Aprano wrote: (A related question - why can't I just go 'if record = method(): use (record)'. Why extra lines just to trap and assign the variable before using it?) Because that idiom is responsible for probably the most common error in C of all, a

Re: Exception as the primary error handling mechanism?

Phlip wrote: > On Jan 5, 8:49 pm, Steven D'Aprano > wrote: > >>> (A related question - why can't I just go 'if record = method(): use >>> (record)'. Why extra lines just to trap and assign the variable before >>> using it?) >> Because that idiom is responsible for probably the most common error

Re: Exception as the primary error handling mechanism?

On 2010-01-06, r0g wrote: > NO! It's a rude way to start a sentence don't you think? No. When somebody asks a yes/no question, answering yes or no seems quite polite to me. Following the yes/no answer with an explanation of the answer is always nice, and I've little doubt that's what happened.

Re: Exception as the primary error handling mechanism?

Phlip wrote: [...] > Don't prevent me from using a technique just because others had > trouble with it. > I presume you also campaign against anti-lock braking systems (or at least don't use cars which have them - after all, anyone who knows how to drive should be able to brake properly, right? An

Re: Exception as the primary error handling mechanism?

On Jan 5, 10:54 pm, Benjamin Kaplan wrote: > {41: None}[41] ? > > In cases where None is a valid result, you can't use it to signal failure. Asked and answered. You change the "sentinel" in .fetch to something else. But y'all keep on defending the language making your programming decisions for

Re: Exception as the primary error handling mechanism?

On Jan 5, 8:49 pm, Steven D'Aprano wrote: > > (A related question - why can't I just go 'if record = method():  use > > (record)'. Why extra lines just to trap and assign the variable before > > using it?) > > Because that idiom is responsible for probably the most common error in C > of all, at

Re: Exception as the primary error handling mechanism?

r0g writes: > NO! It's a rude way to start a sentence don't you think? Shouting is usually rude, yes. > Just because you're correcting someone doesn't mean you have to be > combative and try and make them feel small. Again, you're reading something that isn't there. I utterly deny the motives

Re: Exception as the primary error handling mechanism?

On Tue, Jan 5, 2010 at 8:45 PM, Phlip wrote: > > Here's a super easy example: > >  { 42: 'forty two' }.get(41, None) > > Because I can supply a default, I can decide what is an error and what > is . > > Now the equivalent in a language that does not enjoy this false "Zen": > >  { 42: 'forty two' }

Re: Exception as the primary error handling mechanism?

On Tue, 05 Jan 2010 17:45:58 -0800, Phlip wrote: > On Jan 5, 5:01 pm, Chris Rebert wrote: > >> > Why can't int('nonnumeric') return None? >> >> Errors should never pass silently. > > You are saying I, as the programmer, cannot decide what is an error and > what is a pass-thru. The decision is m

Re: Exception as the primary error handling mechanism?

On Tue, 05 Jan 2010 15:51:29 -0800, Phlip wrote: > Why can't int('nonnumeric') return None? It could do that, but it shouldn't, because returning magic values instead of raising exceptions is usually a bad, bad idea. > (A related question - why can't I just go 'if record = method(): use > (rec

Re: Exception as the primary error handling mechanism?

On Wed, 06 Jan 2010 00:58:58 +, r0g wrote: > Steven D'Aprano wrote: >> On Wed, 06 Jan 2010 09:39:08 +1100, Ben Finney wrote: >> >>> r0g writes: >>> Of course I'm now guilty of pedantry too :/ I might have let it slip had you not started your reply with the word "No", that just p***

Re: Exception as the primary error handling mechanism?

ramming is indeed so fast-and-loose, I refer you to the recent comment about PHP (and other less "exception-happy" languages). Anyway, I do totally agree that you should, if feasible, be provided an easy way to designate a common error-handling strategy (for example, in this case, by using

Re: Exception as the primary error handling mechanism?

> Errors should never pass silently. > Unless explicitly silenced. > -- The Zen of Python (http://www.python.org/dev/peps/pep-0020/) "The person who says it cannot be done should never interrupt the person doing it" -- http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

On Jan 5, 5:01 pm, Chris Rebert wrote: > > Why can't int('nonnumeric') return None? > > Errors should never pass silently. You are saying I, as the programmer, cannot decide what is an error and what is a pass-thru. The decision is made for me. (Yes yes I can write int_or_None(), etc...) Here's

Re: Exception as the primary error handling mechanism?

Lie Ryan wrote: > On 1/6/2010 1:48 AM, r0g wrote: >> Steven D'Aprano wrote: >>> On Tue, 05 Jan 2010 13:06:20 +, r0g wrote: If that's the case how can you expect it to validate anything at all in production? >>> >>> The asserts still operate so long as you don't use the -O switch.

Re: Exception as the primary error handling mechanism?

On Tue, Jan 5, 2010 at 3:51 PM, Phlip wrote: > Peng Yu wrote: >> Otherwise, could some python expert explain to me why exception is >> widely used for error handling in python? Is it because the efficiency >> is not the primary goal of python? > > It's not abo

Re: Exception as the primary error handling mechanism?

Steven D'Aprano wrote: > On Wed, 06 Jan 2010 09:39:08 +1100, Ben Finney wrote: > >> r0g writes: >> >>> Of course I'm now guilty of pedantry too :/ I might have let it slip >>> had you not started your reply with the word "No", that just p* me >>> off. >> Well, if being told “no” is going to p

Re: Exception as the primary error handling mechanism?

Peng Yu wrote: > Otherwise, could some python expert explain to me why exception is > widely used for error handling in python? Is it because the efficiency > is not the primary goal of python? It's not about efficiency, it's about making assumptions for the programmer about

Re: Exception as the primary error handling mechanism?

On Wed, 06 Jan 2010 09:39:08 +1100, Ben Finney wrote: > r0g writes: > >> Of course I'm now guilty of pedantry too :/ I might have let it slip >> had you not started your reply with the word "No", that just p* me >> off. > > Well, if being told “no” is going to piss you off, I think you're i

Re: Exception as the primary error handling mechanism?

r0g writes: > Of course I'm now guilty of pedantry too :/ I might have let it slip > had you not started your reply with the word "No", that just p* me > off. Well, if being told “no” is going to piss you off, I think you're in for a rough time. > Having said that I find the mental image of

Re: Exception as the primary error handling mechanism?

D'Arcy J.M. Cain wrote: > On 05 Jan 2010 14:02:50 GMT > Steven D'Aprano wrote: >> shouldn't use assert for validating user data except for quick-and-dirty >> scripts you intend to use once and throw away. > > A mythcial beast that has yet to be spotted in the wild. > Not true (he wrote, picking

Re: Exception as the primary error handling mechanism?

On 1/6/2010 1:48 AM, r0g wrote: Steven D'Aprano wrote: On Tue, 05 Jan 2010 13:06:20 +, r0g wrote: If that's the case how can you expect it to validate anything at all in production? The asserts still operate so long as you don't use the -O switch. Do you mean for debugging in situ or so

Re: Exception as the primary error handling mechanism?

r0g wrote: Dave Angel wrote: r0g wrote: Maybe, although I recently learned on here that one can't rely on assert statements in production code, their intended use is to aid debugging and testing really. Hopefully, what you learned is that you can't use assert() in product

Re: Exception as the primary error handling mechanism?

Steven D'Aprano wrote: > On Tue, 05 Jan 2010 13:06:20 +, r0g wrote: >> Well maybe I didn't quite get it then, could you explain a bit further? >> >> My understanding was that asserts aren't executed at all if python is >> started with the -O or -OO option, > > Correct. > > >> or run throug

Re: Exception as the primary error handling mechanism?

Ben Finney wrote: > r0g writes: > >> Paul Rudin wrote: >>> Doesn't python just return a single result? (I know it can be a >>> tuple and assignment statements will unpack a tuple for you.) >> Yes, it returns a tuple if you return more than one value, it just has >> a lovely syntax for it. > > No

Re: Exception as the primary error handling mechanism?

On 05 Jan 2010 14:02:50 GMT Steven D'Aprano wrote: > shouldn't use assert for validating user data except for quick-and-dirty > scripts you intend to use once and throw away. A mythcial beast that has yet to be spotted in the wild. -- D'Arcy J.M. Cain | Democracy is three wolves http

Re: Exception as the primary error handling mechanism?

On Tue, 05 Jan 2010 13:06:20 +, r0g wrote: > Dave Angel wrote: >> >> >> r0g wrote: >>> >>> >>> Maybe, although I recently learned on here that one can't rely on >>> assert >>> statements in production code, their intended use is to aid debugging >>> and testing really. >>> >>> >> Hopefully

Re: Exception as the primary error handling mechanism?

In article , r0g wrote: > No, but that's why I try not to use languages where you can only return > a single result, I always found that an arbitrary and annoying > constraint to have. I leads to ugly practices like "magic" return values > in C or explicitly packing things into hashtables like

Re: Exception as the primary error handling mechanism?

Dave Angel wrote: > > > r0g wrote: >> >> >> Maybe, although I recently learned on here that one can't rely on assert >> statements in production code, their intended use is to aid debugging >> and testing really. >> >> > Hopefully, what you learned is that you can't use assert() in productio

Re: Exception as the primary error handling mechanism?

r0g writes: > Paul Rudin wrote: > > Doesn't python just return a single result? (I know it can be a > > tuple and assignment statements will unpack a tuple for you.) > > Yes, it returns a tuple if you return more than one value, it just has > a lovely syntax for it. No, there is nothing inherent

Re: Exception as the primary error handling mechanism?

r0g wrote: Maybe, although I recently learned on here that one can't rely on assert statements in production code, their intended use is to aid debugging and testing really. Hopefully, what you learned is that you can't use assert() in production code to validate user data. It's fine t

Re: Exception as the primary error handling mechanism?

Paul Rudin wrote: > r0g writes: > >> Steven D'Aprano wrote: >>> On Tue, 05 Jan 2010 02:31:34 +, r0g wrote: >>> A pattern I have used a few times is that of returning an explicit success/failure code alongside whatever the function normally returns. >>> That doesn't work for language

Re: Exception as the primary error handling mechanism?

Chris Rebert wrote: > > On Tue, Jan 5, 2010 at 1:07 AM, r0g wrote: >> Lie Ryan wrote: >>> I have been looking at Haskell recently and the way the pure functional >>> language handled exceptions and I/O gives me a new distinct "insight" >>> that exceptions can be thought of as a special return val

Re: Exception as the primary error handling mechanism?

r0g writes: > Steven D'Aprano wrote: >> On Tue, 05 Jan 2010 02:31:34 +, r0g wrote: >> >>> A pattern I have used a few times is that of returning an explicit >>> success/failure code alongside whatever the function normally returns. >> >> That doesn't work for languages that can only return

Re: Exception as the primary error handling mechanism?

Steven D'Aprano wrote: > On Tue, 05 Jan 2010 02:31:34 +, r0g wrote: > >> A pattern I have used a few times is that of returning an explicit >> success/failure code alongside whatever the function normally returns. > > That doesn't work for languages that can only return a single result, > e.

Re: Exception as the primary error handling mechanism?

On Tue, Jan 5, 2010 at 1:07 AM, r0g wrote: > Lie Ryan wrote: >> I have been looking at Haskell recently and the way the pure functional >> language handled exceptions and I/O gives me a new distinct "insight" >> that exceptions can be thought of as a special return value that is >> implicitly wra

Re: Exception as the primary error handling mechanism?

Lie Ryan wrote: > On 1/5/2010 1:31 PM, r0g wrote: >> Michi wrote: >>> On Jan 4, 1:30 pm, Steven D'Aprano >>> wrote: >> A pattern I have used a few times is that of returning an explicit >> success/failure code alongside whatever the function normally returns. >> While subsequent programmers migh

Re: Exception as the primary error handling mechanism?

On Tue, 05 Jan 2010 02:31:34 +, r0g wrote: > A pattern I have used a few times is that of returning an explicit > success/failure code alongside whatever the function normally returns. That doesn't work for languages that can only return a single result, e.g. C or Pascal. You can fake it by

Re: Exception as the primary error handling mechanism?

On 1/5/2010 1:31 PM, r0g wrote: Michi wrote: On Jan 4, 1:30 pm, Steven D'Aprano wrote: In some, limited, cases you might be able to use the magic return value strategy, but this invariably leads to lost programmer productivity, more complex code, lowered readability and usability, and more

Re: Exception as the primary error handling mechanism?

Michi wrote: > On Jan 4, 1:30 pm, Steven D'Aprano > wrote: >> In some, limited, cases you might be able to use the magic return value >> strategy, but this invariably leads to lost programmer productivity, more >> complex code, lowered readability and usability, and more defects, >> because progr

Re: Exception as the primary error handling mechanism?

On Mon, 04 Jan 2010 13:34:34 -0800, Michi wrote: > On Jan 4, 1:30 pm, Steven D'Aprano > wrote: >> >> This is very true, but good APIs often trade-off increased usability >> and reduced defect rate against machine efficiency too. In fact, I >> would argue that this is a general design principle of

  1   2   >