@@ -1120,42 +1120,8 @@ class UpdateMachine {
1120
1120
// or an unexpected exception representing a bug in our code or the server.
1121
1121
// Either way, the show must go on. So reload server data from scratch.
1122
1122
1123
- // First, log what happened.
1124
1123
store.isLoading = true ;
1125
- bool isUnexpected;
1126
- switch (e) {
1127
- case ZulipApiException (code: 'BAD_EVENT_QUEUE_ID' ):
1128
- assert (debugLog ('Lost event queue for $store . Replacing…' ));
1129
- // The old event queue is gone, so we need a new one. This is normal.
1130
- isUnexpected = false ;
1131
-
1132
- case _EventHandlingException (: final cause, : final event):
1133
- assert (debugLog ('BUG: Error handling an event: $cause \n ' // TODO(log)
1134
- ' event: $event \n '
1135
- 'Replacing event queue…' ));
1136
- reportErrorToUserBriefly (
1137
- GlobalLocalizations .zulipLocalizations.errorHandlingEventTitle,
1138
- details: GlobalLocalizations .zulipLocalizations.errorHandlingEventDetails (
1139
- store.realmUrl.toString (), cause.toString (), event.toString ()));
1140
- // We can't just continue with the next event, because our state
1141
- // may be garbled due to failing to apply this one (and worse,
1142
- // any invariants that were left in a broken state from where
1143
- // the exception was thrown). So reload from scratch.
1144
- // Hopefully (probably?) the bug only affects our implementation of
1145
- // the *change* in state represented by the event, and when we get the
1146
- // new state in a fresh InitialSnapshot we'll handle that just fine.
1147
- isUnexpected = true ;
1148
-
1149
- default :
1150
- assert (debugLog ('BUG: Unexpected error in event polling: $e \n ' // TODO(log)
1151
- 'Replacing event queue…' ));
1152
- _reportToUserErrorConnectingToServer (e);
1153
- // Similar story to the _EventHandlingException case;
1154
- // separate only so that that other case can print more context.
1155
- // The bug here could be in the server if it's an ApiRequestException,
1156
- // but our remedy is the same either way.
1157
- isUnexpected = true ;
1158
- }
1124
+ final isUnexpected = _triagePollError (e);
1159
1125
1160
1126
if (isUnexpected) {
1161
1127
// We don't know the cause of the failure; it might well keep happening.
@@ -1185,6 +1151,48 @@ class UpdateMachine {
1185
1151
reportErrorToUserBriefly (null );
1186
1152
}
1187
1153
1154
+ /// Sort out an error in [poll] .
1155
+ ///
1156
+ /// Reports the error if appropriate to the user and/or developer;
1157
+ /// then returns true just if the error was unexpected.
1158
+ bool _triagePollError (Object error) {
1159
+ bool isUnexpected;
1160
+ switch (error) {
1161
+ case ZulipApiException (code: 'BAD_EVENT_QUEUE_ID' ):
1162
+ assert (debugLog ('Lost event queue for $store . Replacing…' ));
1163
+ // The old event queue is gone, so we need a new one. This is normal.
1164
+ isUnexpected = false ;
1165
+
1166
+ case _EventHandlingException (: final cause, : final event):
1167
+ assert (debugLog ('BUG: Error handling an event: $cause \n ' // TODO(log)
1168
+ ' event: $event \n '
1169
+ 'Replacing event queue…' ));
1170
+ reportErrorToUserBriefly (
1171
+ GlobalLocalizations .zulipLocalizations.errorHandlingEventTitle,
1172
+ details: GlobalLocalizations .zulipLocalizations.errorHandlingEventDetails (
1173
+ store.realmUrl.toString (), cause.toString (), event.toString ()));
1174
+ // We can't just continue with the next event, because our state
1175
+ // may be garbled due to failing to apply this one (and worse,
1176
+ // any invariants that were left in a broken state from where
1177
+ // the exception was thrown). So reload from scratch.
1178
+ // Hopefully (probably?) the bug only affects our implementation of
1179
+ // the *change* in state represented by the event, and when we get the
1180
+ // new state in a fresh InitialSnapshot we'll handle that just fine.
1181
+ isUnexpected = true ;
1182
+
1183
+ default :
1184
+ assert (debugLog ('BUG: Unexpected error in event polling: $error \n ' // TODO(log)
1185
+ 'Replacing event queue…' ));
1186
+ _reportToUserErrorConnectingToServer (error);
1187
+ // Similar story to the _EventHandlingException case;
1188
+ // separate only so that that other case can print more context.
1189
+ // The bug here could be in the server if it's an ApiRequestException,
1190
+ // but our remedy is the same either way.
1191
+ isUnexpected = true ;
1192
+ }
1193
+ return isUnexpected;
1194
+ }
1195
+
1188
1196
/// This only reports transient errors after reaching
1189
1197
/// a pre-defined threshold of retries.
1190
1198
void _maybeReportToUserTransientError (Object error) {
0 commit comments