id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
145	make DeadReferenceError qualify as RemoteException	Brian Warner		"[http://allmydata.org/trac/tahoe/ticket/889#comment:14 Tahoe#889] indicates a place where some logging code was surprised to see {{{DeadReferenceError}}} qualify as a ""local"" exception (and thus got logged with more severity than intended). When I wrote that logging code, I had expected {{{DeadReferenceError}}} to qualify as remote, via {{{f.check(RemoteException)}}}.

I'd like to fix this, so that code which does {{{f.check(RemoteException)}}} will catch {{{DeadReferenceError}}}. On the other hand, it is useful for clients to spot {{{DeadReferenceError}}} easily, because they typically respond to it by dropping the connection or trying to establish a new one (as opposed to other remote errors that don't affect the connection).

I'd like to make this use of {{{f.check}}} work for both the {{{DeadReferenceErrors}}} that occur when you lose the connection while the request is outstanding, and for the ones that occur when the connection is already gone by the time you call {{{callRemote}}}. These are delivered via two separate code paths. I believe (but haven't confirmed) that the former code path wraps the {{{DeadReferenceError}}} in a {{{RemoteException}}}, but the latter does not.

So I'm considering making {{{DeadReferenceError}}} simply inherit from {{{RemoteException}}}. The downside of this would be that code which does {{{f.check(RemoteException)}}} could not also just do {{{f.value.failure.check}}}, because these {{{DeadReferenceErrors}}} would not have a .failure attribute. This would be a significant compatibility burden.

The alternative would be to have the {{{callRemote}}}-side path also wrap its {{{DeadReferenceError}}} in a {{{RemoteException}}}. This would means that application code would never see {{{callRemote}}} errback with {{{DeadReferenceError}}}, so code which wanted to handle lost connections specially would have to be updated. This affects backwards compatibility too.
"	enhancement	closed	major	0.5.0	error-handling	0.4.1	wontfix