On 2019-02-22 17:20, Chris Angelico wrote:
> On Sat, Feb 23, 2019 at 9:14 AM Kyle Lahnakoski
> wrote:
>> Can Python provide better support for the CNCR pattern? If it is
>> lightweight enough, maybe people will use it, and then we can say
>> something useful about the (restricted) range of
On Sat, Feb 23, 2019 at 9:14 AM Kyle Lahnakoski wrote:
> Let me call this pattern the Catch-It-Name-It-Chain-It-Raise-It (CNCR)
> pattern
>
> There are a few reasons for this.
>
> 1. I can add runtime values to the exception so I get a better sense of
> the program state without going to the
On 2019-02-21 03:09, Christopher Barker wrote:
>
> But yes, there is no (easy) way to distinguish an Exception raised by
the function you called, and one raised somewhere deeper that.
>
> And I have been bitten by that more than once. It makes "Easier to ask
forgiveness than permission" kind of
On Thu, Feb 21, 2019 at 11:32 PM Chris Angelico wrote:
> On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez wrote:
> > Then, if exceptions are going to be part of a type, there should be a
> way to express the semantics of them (like in Eiffel), so
> stack.pop();stack.push(x) doesn't have to catch
On Sat, Feb 23, 2019 at 5:32 AM Juancarlo Añez wrote:
> On Thu, Feb 21, 2019 at 11:32 PM Chris Angelico wrote:
>>
>> On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez wrote:
>> > Then, if exceptions are going to be part of a type, there should be a way
>> > to express the semantics of them (like
On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez wrote:
> Then, if exceptions are going to be part of a type, there should be a way to
> express the semantics of them (like in Eiffel), so stack.pop();stack.push(x)
> doesn't have to catch StackFullException.
>
That assumes atomicity. If you want
On Thu, Feb 21, 2019 at 10:34 PM Ben Rudiak-Gould
wrote:
> > It's well documented how checked exceptions lead to bad code.
>
> Please cite a paper. I know "everyone knows" that they're bad, but
> "everyone knows" a lot of things.
>
This is one of the original interviews touching why checked
> It's well documented how checked exceptions lead to bad code.
Please cite a paper. I know "everyone knows" that they're bad, but
"everyone knows" a lot of things.
Here's a recentish proposal by Herb Sutter to add a kind of checked
exception to C++:
On Thu, Feb 21, 2019 at 6:28 PM Ivan Levkivskyi
wrote:
> The idea about "checked exceptions" appeared several times in various
> places. I used to think that this would be hard to support for any
> realistic use cases. But now I think there may be a chance
> to turn this into a usable feature if
On Tue, 19 Feb 2019 at 21:07, Miikka Salminen
wrote:
> Hi!
>
> To help automatic document generators and static type checkers reason more
> about the code, the possible side-effects and raised exceptions could also
> be annotated in a standardized way.
>
The idea about "checked exceptions"
On Thu, Feb 21, 2019 at 10:04 PM Steven D'Aprano wrote:
>
> On Thu, Feb 21, 2019 at 07:05:55PM +1100, Chris Angelico wrote:
>
> [Ben]
> > > Other functions also conceptually have three ways of returning:
> > > ordinary return with a value, a documented special return like
> > > KeyError, and
On Thu, Feb 21, 2019 at 07:05:55PM +1100, Chris Angelico wrote:
[Ben]
> > Other functions also conceptually have three ways of returning:
> > ordinary return with a value, a documented special return like
> > KeyError, and pass-through exceptions. If the pass-through exception
> > is KeyError, it
On Wed, Feb 20, 2019 at 11:52 PM Ben Rudiak-Gould
wrote:
> Other functions also conceptually have three ways of returning:
> ordinary return with a value, a documented special return like
> KeyError, and pass-through exceptions.
well, I wouldn't call that three ways of returning...
But yes,
On Thu, Feb 21, 2019 at 6:51 PM Ben Rudiak-Gould wrote:
>
> On Wed, Feb 20, 2019 at 2:43 AM Chris Angelico wrote:
> > That's because a generator function conceptually has three ways to
> > provide data (yield, return, and raise), but mechanically, one of them
> > is implemented over the other
On Wed, Feb 20, 2019 at 2:43 AM Chris Angelico wrote:
> That's because a generator function conceptually has three ways to
> provide data (yield, return, and raise), but mechanically, one of them
> is implemented over the other ("return" is "raise StopIteration with a
> value"). For other raised
On Wed, Feb 20, 2019 at 9:09 PM Ben Rudiak-Gould wrote:
> That problem, of an inadvertently leaked implementation detail
> masquerading as a proper alternate return value, used to be a huge
> issue with StopIteration, causing bugs that were very hard to track
> down, until PEP 479 fixed it by
On Tue, Feb 19, 2019 at 3:19 PM Steven D'Aprano wrote:
> And I note that in Java, where the idea of checked exceptions
> originated, it turned out to be full of problems and a very bad idea.
What should be the default behavior of a language when the programmer
doesn't explicitly handle an error?
Chris Angelico wrote:
if I'd been able to ascertain which functions were pure, or
at least side-effect-free, it would have saved me a lot of hassle.)
I'm not sure how useful such annotations would be in practice,
though. They're only as good as the diligence of the author in
using them
On Wed, Feb 20, 2019 at 10:18 AM Steven D'Aprano wrote:
> So the promises made will nearly always be incredibly weak:
>
> - raises(A) means "may raise A, or any other unexpected exception"
> - sideeffects(True) means "may have expected side-effects"
> - sideeffects(False) means "may have
On Tue, Feb 19, 2019 at 11:05:55PM +0200, Miikka Salminen wrote:
> Hi!
>
> To help automatic document generators and static type checkers reason more
> about the code, the possible side-effects and raised exceptions could also
> be annotated in a standardized way.
This is Python. Nearly
Hi!
To help automatic document generators and static type checkers reason more
about the code, the possible side-effects and raised exceptions could also
be annotated in a standardized way.
I'll let some example code talk on my behalf. Here's a simple decorator for
annotating exceptions:
In
21 matches
Mail list logo
