"Simon Willison" <[EMAIL PROTECTED]> writes:
> Hi all,
>
> I have an API design question. I'm writing a function that can either
> succeed or fail. Most of the time the code calling the function won't
> care about the reason for the failure, but very occasionally it will.
>
> I can see a number
Simon Willison wrote:
> Hi all,
>
> I have an API design question. I'm writing a function that can either
> succeed or fail. Most of the time the code calling the function won't
> care about the reason for the failure, but very occasionally it will.
>
> I can see a number of ways of doing this, bu
In article <[EMAIL PROTECTED]>,
Simon Willison <[EMAIL PROTECTED]> wrote:
>
>try:
> do_something()
>except HttpError:
> # An HTTP error occurred
>except ApplicationError:
> # An application error occurred
>else:
> # It worked!
Use a similar but different idiom:
try:
do_something()
except
Steve Holden <[EMAIL PROTECTED]> writes:
> I should have thought the simplest spelling of your requirements would be
>
> try:
> do_something()
> print "It worked"
> except:
> # it didn't
This usage is generally disparaged because of the possibility of
exceptions having nothing to d
Steve Holden wrote:
> Simon Willison wrote:
>
>>Hi all,
>>
>>I have an API design question. I'm writing a function that can either
>>succeed or fail. Most of the time the code calling the function won't
>>care about the reason for the failure, but very occasionally it will.
>>
>>I can see a number
Simon Willison wrote:
> I have an API design question. I'm writing a function that can either
> succeed or fail. Most of the time the code calling the function won't
> care about the reason for the failure, but very occasionally it will.
>
> I can see a number of ways of doing this, but none of th
Simon Willison wrote:
> Hi all,
>
> I have an API design question. I'm writing a function that can either
> succeed or fail. Most of the time the code calling the function won't
> care about the reason for the failure, but very occasionally it will.
>
> I can see a number of ways of doing this, b
Simon Willison enlightened us with:
> try:
> do_something()
> except HttpError:
> # An HTTP error occurred
> except ApplicationError:
> # An application error occurred
> else:
> # It worked!
>
> This does the job fine, but has a couple of problems.
> I anticipate that most people using my
Hi all,
I have an API design question. I'm writing a function that can either
succeed or fail. Most of the time the code calling the function won't
care about the reason for the failure, but very occasionally it will.
I can see a number of ways of doing this, but none of them feel
aesthetically p
