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
Copy file name to clipboardExpand all lines: README.md
+84Lines changed: 84 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -209,3 +209,87 @@ Here, the code leverages the specific error types to implement various kinds of
209
209
### Summary
210
210
211
211
By utilizing these typed-throws overloads, you can write more robust and maintainable code. ErrorKit's enhanced user-friendly messages and ability to handle specific errors with code lead to a better developer and user experience. As the library continues to evolve, we encourage the community to contribute additional overloads and error types for common system APIs to further enhance its capabilities.
212
+
213
+
214
+
## Built-in Error Types for Common Scenarios
215
+
216
+
ErrorKit provides a set of pre-defined error types for common scenarios that developers encounter frequently. These built-in types conform to `Throwable` and can be used with both typed throws (`throws(DatabaseError)`) and classical throws declarations.
217
+
218
+
### Why Built-in Types?
219
+
220
+
Built-in error types offer several advantages:
221
+
-**Quick Start**: Begin with well-structured error handling without defining custom types
222
+
-**Consistency**: Use standardized error cases and messages across your codebase
223
+
-**Flexibility**: Easily transition to custom error types when you need more specific cases
224
+
-**Discoverability**: Clear naming conventions make it easy to find the right error type
225
+
-**Localization**: All error messages are pre-localized and user-friendly
226
+
-**Ecosystem Impact**: As more Swift packages adopt these standardized error types, apps can implement smarter error handling that works across dependencies. Instead of just showing error messages, apps could provide specific UI or recovery actions for known error types, creating a more cohesive error handling experience throughout the ecosystem.
227
+
228
+
### Available Error Types
229
+
230
+
ErrorKit includes the following built-in error types:
All built-in error types include a `generic` case that accepts a custom `userFriendlyMessage`, allowing for quick additions of edge cases without creating new error types. Use the `GenericError` struct when you want to quickly throw a one-off error without having to define your own type if none of the other fit, useful especially during early phases of development.
throwGenericError(userFriendlyMessage: String(localized: "The condition X was not fulfilled, please check again."))
266
+
}
267
+
// Operation logic
268
+
}
269
+
270
+
// Using generic case for edge cases
271
+
funchandleSpecialCase() throws(DatabaseError) {
272
+
guard specialCondition else {
273
+
throw .generic(userFriendlyMessage: String(localized: "Database is in maintenance mode"))
274
+
}
275
+
// Special case handling
276
+
}
277
+
```
278
+
279
+
### Contributing New Error Types
280
+
281
+
We need your help! If you find yourself:
282
+
- Defining similar error types across projects
283
+
- Missing a common error scenario in our built-in types
284
+
- Seeing patterns in error handling that could benefit others
285
+
- Having ideas for better error messages or new cases
286
+
287
+
Please contribute! Submit a pull request to add your error types or cases to ErrorKit. Your contribution helps build a more robust error handling ecosystem for Swift developers.
288
+
289
+
When contributing:
290
+
- Ensure error cases are generic enough for broad use
291
+
- Provide clear, actionable error messages
292
+
- Include real-world usage examples in documentation
293
+
- Follow the existing naming conventions
294
+
295
+
Together, we can build a comprehensive set of error types that cover most common scenarios in Swift development and create a more unified error handling experience across the ecosystem.
0 commit comments