You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -150,7 +158,7 @@ ErrorHandler is __thread-safe__.
150
158
151
159
*`on(Class<? extends Exception>, Action)` Register an _Action_ to be executed if error is an instance of `Exception`.
152
160
153
-
*`on(T, Action)` Register an _Action_ to be executed if error is bound to T, through `bindErrorCode()` or `bindErrorCodeClass()`.
161
+
*`on(T, Action)` Register an _Action_ to be executed if error is bound to T, through `bind()` or `bindClass()`.
154
162
155
163
*`otherwise(Action)` Register an _Action_ to be executed only if no other _Action_ gets executed.
156
164
@@ -162,9 +170,9 @@ ErrorHandler is __thread-safe__.
162
170
163
171
*`skipDefaults()` Skip any default actions. Meaning any actions registered on the `defaultErrorHandler` instance.
164
172
165
-
*`bindErrorCode(T, MatcherFactory<T>)` Bind instances of _T_ to match errors through a matcher provided by _MatcherFactory_.
173
+
*`bind(T, MatcherFactory<T>)` Bind instances of _T_ to match errors through a matcher provided by _MatcherFactory_.
166
174
167
-
*`bindErrorCodeClass(Class<T>, MatcherFactory<T>)` Bind class _T_ to match errors through a matcher provided by _MatcherFactory_.
175
+
*`bindClass(Class<T>, MatcherFactory<T>)` Bind class _T_ to match errors through a matcher provided by _MatcherFactory_.
168
176
169
177
*`clear()` Clear all registered _Actions_.
170
178
@@ -174,23 +182,18 @@ ErrorHandler is __thread-safe__.
174
182
175
183
176
184
## About
177
-
A common problem in software, specially in UI software is that of error handling.
178
-
179
-
One way to classify errors can be by how they relate to the [problem domain](https://en.wikipedia.org/wiki/Problem_domain). Some errors, like `network` or `database` errors are orthogonal to the problem domain and designate truly **exceptional conditions**, while others are core parts of the domain like `validation` and `authentication` errors.
180
-
181
-
Another way to classify errors is by their **scope**. Are they **common** throughout the application or **specific** to a single screen, object or even method? Think of `UnauthorizedException` versus `InvalidPasswordException`.
182
-
183
-
And let's not forget another very simple distinction between errors. Those that are known at authoring time and thus **expected** (despite of how probable is that they occur), and those that are **unknown** until runtime.
184
185
185
-
With that in mind, we usually want to:
186
+
When designing for errors, we usually need to:
186
187
187
-
1. have a **default** handler for every **expected** (exceptional, common or not) error
188
-
2. handle **specific** errors **as appropriate** based on where and when they occur
189
-
3. have a **default** catch-all handler for **unknown** errors
190
-
4.**override** any default handler if needed
191
-
5. keep our code **DRY**
188
+
1. have a **default** handler for every **expected** error
189
+
// i.e. network, subscription errors
190
+
2. handle **specific** errors **as appropriate** based on where and when they occur
191
+
// i.e. network error while uploading a file, invalid login
192
+
3. have a **catch-all** handler for **unknown** errors
193
+
// i.e. system libraries runtime errors we don't anticipate
194
+
4. keep our code **DRY**
192
195
193
-
Java, as a language, provides you with a way to do the above. By mapping exceptional or very common errors to runtime exceptions and catching them lower in the call stack, while having specific expected errors mapped to checked exceptions and handle them near where the error occurred. Still, countless are the projects where this simple strategy has gone astray with lots of errors being either swallowed or left for the catch-all `Thread.UncaughtExceptionHandler`. Moreover, it usually comes with significant boilerplate code. `ErrorHandler` however eases this practice through its fluent API, error aliases and defaults mechanism.
196
+
Java, as a language, provides you with a way to do the above. By mapping cross-cutting errors to runtime exceptions and catching them lower in the call stack, while having specific expected errors mapped to checked exceptions and handle them near where the error occurred. Still, countless are the projects where this simple strategy has gone astray with lots of errors being either swallowed or left for the catch-all `Thread.UncaughtExceptionHandler`. Moreover, it usually comes with significant boilerplate code. `ErrorHandler` however eases this practice through its fluent API, error aliases and defaults mechanism.
194
197
195
198
This library doesn't try to solve Java specific problems, although it does help with the `log and shallow` anti-pattern as it provides an opinionated and straightforward way to act inside every `catch` block. It was created for the needs of an Android app and proved itself useful very quickly. So it may work for you as well. If you like the concept and you're developing in _Swift_ or _Javascript_, we're baking 'em and will be available really soon.
Copy file name to clipboardExpand all lines: errorhandler-matchers/retrofit-rx-matcher/src/main/java/com/workable/errorhandler/matchers/retrofit/Range.java
+6-4Lines changed: 6 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -10,9 +10,10 @@ public class Range {
10
10
11
11
/**
12
12
* Creates a Range object with lower and upper bound
Copy file name to clipboardExpand all lines: errorhandler-matchers/retrofit-rx-matcher/src/main/java/com/workable/errorhandler/matchers/retrofit/RetrofitMatcherFactory.java
Copy file name to clipboardExpand all lines: errorhandler-matchers/retrofit-rx-matcher/src/test/java/com/workable/errorhandler/matchers/retrofit/RetrofitMatcherFactoryTest.java
0 commit comments