Search for a command to run...
I am an iOS Developer from Egypt, Cairo who likes Apple Products and UX studies
I enjoy reading about Entreprenuership and Scrum.
When no one is looking, I like to play around with Figma and build tools/ideas to help me during get things done quickly.
And I keep repeating epic gaming moments over and over again in my head and repeat narratives out loud in my room to regain a glimpse of how it felt when I first saw it (without altering the script)
No comments yet. Be the first to comment.
A series about a set of techniques that improves your project's fail tolerance and allows for better quality monitoring and UX
Hello there! 👋 It’s been a while, and I really missed writing a blog early in the morning! Now that I have some sort of free time, I wanted to discuss some techniques in Error handling over the coming days that I learned, and well, thought it would ...
Navigating the Complexities of Domain-Driven Design: Bridging Tech and Business with Clarity and Bounded Contexts
And the start of a Journey with another DDD Book
How Command Pattern can be easily translated to Siri features
Breaking the Chains of Massive View Controllers: Lessons for SwiftUI and Beyond
A New day... a new productive day where my tiny blog gains a new post! https://tenor.com/view/terrific-tuesday-gif-25021333 Today is a bit of a quick one, its about a productivity tip you can imply if you work a lot with terminals, so without furth...
Hello, Folks!
Finally, this series is seeing its ending so I can move to other series!
Well... you might have noticed that async-await does indeed make code much more readable, and easier to handle. and the fact of allowing the compiler to help you define Race Conditions and Non-Thread-safe code via 'Sendable', Nonsendable, Actors, and Structured Concurrency... makes adopting async-await a very common goal for many tech teams these days... and today is a lesson I wanted to share with you what I've learned recently...
but before we start with our learning, I just wanna say...
Alright, Detectives, I've just binged-watched 6 seasons of Brooklyn 99, and today am Jake Peralta, and today, we are investigating...
Defined Errors and how they can screw your design... title of your bug report
The throws keyword in this statement
func fetchRecentWalletTransactions() async throws -> [Transaction] { ... }
Now, don't get me wrong; after all, this is not an async-await series, nor am I asking you to ignore errors (it's an Error Handling Series after all 😬)
But as innocent, and tiny and so inline with the best practices of Clean Code & Swift Documentation, this keyword, can do you bad in terms of software design and maintainability of your layers...
How many errors can I throw from this method alone?
enum WalletTransactionFetchError: Error {
case walletAccountNotSetup
case walletUnavailable(reason: String)
case walletOnHold
case noTransactions
}
Well, Yep, seems like a good start... but is that all?
You can throw anything that conforms to Error, and for now, that's ok, or so it seemed
Due to not being specific, we lost being specific about what's going wrong, and supplying to our dependents what actually happened, so they have to do some guesswork, and that's where we lost the way, so now we're here, in the crime scene (the codebase), and trying to identify our characters...
The method itself (Prime Suspect)
The invokers (Victims)
Expectations between layers (Witnesses)
Mostly here, there won't be much trouble found..., upon fetching, you found that there is an issue, and you begin to map it to the above enum cases, however, worst case scenario, you can say, .walletUnavailable with a reason, right?
Like any RPG or a story with multiple protagonists, each has their own side of the story, and let me tell you something, the Invoker is not HAPPY, about it...
I mean, you had one job! Fetching the transactions...
class TransactionWidgetViewModel {
...
func onAppear() async {
do {
async try transactionsUsecase.fetchRecentWalletTransactions()
} catch let error WalletTransactionFetchError {
// some handling
} catch {
// Default handling
}
}
}
Now, this went quickly from 'handling the fetch error', to 'guess what broke'
The problem here is... if there are multiple error types, that means the method we built above may be doing two things or more... which may be a sign of SRP violation...
Similarly, the default handling is another place we would like to avoid...
because if our code reached this point, that means there is an invalid state, the application is currently in, and to quickly recover from it, we map it into a something went wrong error...
Lastly, if we were to handle each case, and if there is a new case that popped up which require its own handling, we might also break the OCP, which is another word for a...
Remember the Error Flow episode?
We were mentioning how each layer would expect an error of some sort from its dependency, or layer... but now that the only thing we get is any Error, we gotta try to see if its the error we're expecting, or just wrap it inside a 'something went wrong', or an object with more metadata to describe it better later on (or not... since its a bit risky and some guess-work is involved)
so... in a nutshell, if we were to summarize all the above in one image... this one does a pretty good job at it 👇
Alright, now that we have an idea of what's wrong, let's check an approach that addresses it
func fetchRecentWalletTransactions() async -> Result<[Transaction], WalletTransactionFetchError> { ... }
A simple, non-fancy, and weird-looking solution would be to return to Result<Success, Failure>
The reason for this is I can specify why this method can fail and the scenarios that follow it up... so the invokers can react accordingly
func onAppear() async {
let result = async transactionUsecase.fetchRecentWalletTransactions()
switch result {
case let .success(...):
...
case let .failure(error):
handle(fetchError: error)
}
}
func handle(fetchError: WalletTransactionFetchError) { ... }
It seems kinda familiar to how we used to handle errors when we depended on callbacks, and the syntax was kinda boring...
Now that we have learned Defined Errors and their importance, It's high time I start working on that blog about monitoring the errors and how important this is as a practice 👏