Starts running the callback chain. This posts the initial result that will be passed to the first callback in the callback chain. If the argument is an Exception then the "errback" chain will be triggered instead. This method will not let any Exception thrown by a callback p
(final Object initresult)
| 975 | * @throws AssertionError if {@code initresult == this}. |
| 976 | */ |
| 977 | public void callback(final Object initresult) { |
| 978 | if (!casState(PENDING, RUNNING)) { |
| 979 | throw new AssertionError("This Deferred was already called!" |
| 980 | + " New result=" + initresult + ", this=" + this); |
| 981 | } |
| 982 | result = initresult; |
| 983 | if (initresult instanceof Deferred) { |
| 984 | // Twisted doesn't allow a callback chain to start with another Deferred |
| 985 | // but I don't see any reason. Maybe it was to help prevent people from |
| 986 | // creating recursive callback chains that would never terminate? We |
| 987 | // already check for the obvious in handleContinuation by preventing |
| 988 | // this Deferred from depending on itself, but there's no way to prevent |
| 989 | // people from building mutually dependant Deferreds or complex cyclic |
| 990 | // chains of Deferreds, unless we keep track in a set of all the |
| 991 | // Deferreds we go through while executing a callback chain, which seems |
| 992 | // like an unnecessary complication for uncommon cases (bad code). Plus, |
| 993 | // when that actually happens and people write buggy code that creates |
| 994 | // cyclic chains, they will quickly get a CallbackOverflowError. |
| 995 | final Deferred d = (Deferred) initresult; |
| 996 | if (this == d) { |
| 997 | throw new AssertionError("A Deferred cannot be given to itself" |
| 998 | + " as a result. this=" + this); |
| 999 | } |
| 1000 | handleContinuation(d, null); |
| 1001 | } |
| 1002 | runCallbacks(); |
| 1003 | } |
| 1004 | |
| 1005 | /** |
| 1006 | * Synchronously waits until this Deferred is called back. |
no test coverage detected