#twisted

Tickets pending review: https://tm.tl/#8464 (rodrigc), #8902, #8912, #8966 (the0id), #8981, #8995, #9024, #9015, #9006, #9017, #5726, #9014, #9027, #9028

nanonyme: IMO an API method should either return a Deferred or not (and thus, all-Failures or all-exceptions)

also, maybeDeferred it pretty simple code, I doubt it would induce that much slowness

Does anyone have any good examples of how to use multiservice?

Tickets pending review: https://tm.tl/#8464 (rodrigc), #8902, #8912, #8966 (the0id), #8981, #8995, #9024, #9015, #9006, #9017, #5726, #9014, #9027, #9028

Tickets pending review: https://tm.tl/#8464 (rodrigc), #8902, #8912, #8966 (the0id), #8981, #8995, #9024, #9015, #9006, #9017, #5726, #9014, #9027, #9028

so I feel really stupid, but why would `twist web -p "tls:cust-ws.service.consul:443:privateKey=/etc/ssl/private/*.service.consul.key" --wsgi cust_ws.wsgi.application` return `ValueError: Unknown endpoint type: 'tls'` ? is the new and shiny tls type legacy Python-only?

hynek: perhaps you didn't install twisted[tls] ?

random thought, but hey, maybe

meejah, yes, imo that would be reasonable assumption as well

meejah, https://paste.fedoraproject.org/547104/63052771/ I just wonder whose responsibility here is to make sure that exceptions are rolled into deferred failures

Or should *every* frame that claims they return a Deferred always catch exceptions and roll them into deferred failures?

i don't think it's sane to take special care to make sure your function never throws an exception (and instead returns a failure) - because in python, mostly everything can possibly throw an exception, right

but in this case this looks like something i'd call validation i guess, so yeah, if it's part of the api, it should probably return a failure instead

asdf, that way of thinking means you can't rely on any Twisted API and must always use maybeDeferred

i mean in a "exceptions you know how to handle / expected by the programmer" vs "exceptions that you don't handle (which should bubble up)"

I mean, you can't really know what some other library will raise. You just have to turn *everything* into a Failure if you want your API to reliably return a Deferred

(i dont think the latter need to be failures)

Okay, so someone who actually can handle all failures then needs to wrap everything as maybeDeferred

As in, like, my errback handler was basically "okay, this URl failed, I'm going to log error and add it to ignore list"

Instead the synchronous exception went in some weird codepaths and apparently broke my reactor

exarkun submitted <https://tm.tl/#9021>; - twisted.python._url.URL docstring for .child() method is incorrect (unassigned) for review

hynek: from all i'm seeing it should be 'ssl', not 'tls'

asdf, and seriously my assumption was *everything* is Failures, then you trap in your errback

Apparently you just can't code like this in significant bulks of Twisted

I mean, having two parallel flow controls is just silly

Tickets pending review: https://tm.tl/#8464 (rodrigc), #8902, #8912, #8966 (the0id), #8981, #8995, #9024, #9015, #9006, #9021, #9017, #5726, #9014, #9027, #9028

Julian reviewed <https://tm.tl/#9021>; - twisted.python._url.URL docstring for .child() method is incorrect (assigned to exarkun)

nanonyme: if a function is @inlineCallback-decorated then any exception will become a Failure. And ditto for maybeDeferred. but yeah I imagine stuff like SyntaxError will often be a synchronous exception for "normal" Deferred-returning functions

meejah, well, as in my traceback above, this was actually just some parse error in a string which was raised but layers of Twisted left it not wrapped as Failure since they were only doing it for expected exception types

Even when the API documented that these things always return Deferred's

I'm here trying to find some core devs to argue on this since it seems a philosophical thing to me and I don't want to start filing tickets until I've checked whether my idea is the same as with core devs'

I basically workarounded my specific case with maybeDeferred but it feels like a workaround to me

cdunklau: ssl: is deprecated in favor of TLS:…

Well, not deprecated in that it likely won't be removed any time soon.

nanonyme: yeah i'm not sure if there's a policy, but effectively all you're asking for is every public-API to be wrapped in maybeDeferred ;)

meejah, I guess. For every public API that isn't documented not to return a deferred anyway

But I think more that there would be a guarantee that API's that return a deferred never raise directly and whenever you hit a boundary between an API that does not return deferred, you wrap the return value and exception

So that you don't necessarily do it at public API level but API boundary level

If that makes any sense to you

sort-of. but i'm a little ambivilant on straight-up errors like SyntaxError etc

not that i'm a core twisted dev ;) so *shruggy-face* but ...

i've been using @inlineCallbacks "mostly" in a lot of my stuff, making that a sort of non-issue

There are arguments either way.

It is impossible to catch everything without doing `except:` everywhere which is problematic for other reasons.

Often, raising an exception is a bug.

tomprince, I'd be fine with even Exception being wrapped

On the other hand, an argument could be made that raising an exception is reasonable, if a function was passed nonsense, rather than couldn't do what was asked.

tomprince, http://paste.fedoraproject.org/547104/63052771/ is the stack trace that made me start wondering about all of this FWIW

Probably glyph has some thoughts.

I was assuming in that case that I could just *always* do errbacks but turned out I was wrong

nanonyme: can you share app.py?

if you raise an exception in a deferred's callback, it will automatically get converted to a failure

Sure, nanobot is opensource

so that covers a lot of cases

runciter, the thing is, the API that was supposed to give me a deferred never did but raised an exception instead

here, you seem to be using a cooperator

runciter, I used maybeDeferred and the problem went away

nanonyme: yeah, if an exception occurs *before* the callbacks can run, then it will propogate synchronously

I would have had an errback to handle the error from the defered

runciter, https://github.com/nanonyme/nanobot/blob/master...

ok so https://github.com/nanonyme/nanobot/blob/master...

to here https://github.com/nanonyme/nanobot/blob/master...

Yes

And the exception gets raised on line 201

so the Cooperator API is special

you give it an iterable that yields deferreds

I was expecting a deferred instead

this is distinct from inlineCallbacks

in that the generator will be wrapped in a Deferred automatically

so with Cooperator there's this gap where your iterator can throw an exception and it will be raised synchronously

You're not getting it, I think

nanonyme: my point is that this there isn't a general code path here

the common code path is covered - getting an exception in a callback or errback

runciter, what do you mean general?

but that's not the path you're hitting

The problem is that there is no deferred here

nanonyme: you're asking about how you can generally manage exceptions in twisted

i think

and your argument is: wrap everything in maybeDeferred, so you always get a Failure

i think

No, I'm saying that API's that are documented that they return a deferred shouldn't randomly raise