UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

SOLVED: Question: Do we have to use "throw errors " very often in APP development ?

Forums > 100 Days of SwiftUI

@boat  

I noticed that :

Though throw errors is essentially a function (https://www.hackingwithswift.com/quick-start/beginners/how-to-handle-errors-in-functions_), the syntax of calling this special function is more complicated than other functions.

For normal functions we call like:

functionA ()

But for error throwing, we need to call with the syntax :

do {

 try (function A) {
 }

 catch {
 }

My questions are:

1, Is it always so complicated to throw errors ?

2, When it comes to app development, there might be errors need to be thrown, such as "you can't plant the tree there", "tell us the model of the laptop you want to sell".

Should developers get used to error throwing and make it like a go-to ? Or can we solve it by using pickers than textfield, so we can limit users' options when it comes to interaction, so they won't mess up.

Thanks in advance,

Boat

2      

You should defintitely get used to how to handle errors.

Every so often it's not a nice user experience to handle all with fatalError(). When a network call fails (for what reason ever) you have to let the user know that there was something wrong and explain it to them. On the other hand it's important for you to know what the user did and which error message he got. So you can identify bugs much faster.

If you rely on an API which throws errors you almost everytime use the do catch variant. If it's something you wrote yourself you can choose to how to handle the errors. guard let, switch what ever works best for you. In my opinion the most work goes into letting the user know what went wrong. And in a way which is understandable for a not programmer.

2      

Maybe another Obelix example?

In the service industry, you want your clerks to handle as many customer problems as possible. Handle the problem at the lowest level you can.

If the customer wants two bags, give them two bags. If they want their receipt handed to them, don't put it in the bag. Likewise, If you're trying to multiply two numbers, but the programmer only gave you one? Let the guard statement end the function early. Easy. There are 100s of ways you handle issues at the lower levels of your code.

However, there are times when it might not be appropriate for your lower level code to fix the problem. There may be numerous and varied error codes to consider, or the issue isn't with the user or the program, but with the network, or security, or file storage.

These are problems not easily solved by your lower level code. This is where your function might say "this is above my paygrade to solve" and you'll pass the error UP the chain-of-command to a floor supervisor, or to the department manager. Let THEM deal with the problem. In programming speak, you THROW the error, and let another process CATCH it. In some cases, a process might catch an error, decide it can't solve the problem either and it will re-THROW the error. In short, the clerk gives the problem to the floor supervisor. The floor supervisor can't solve the problem and passes it up to the department manager.

Additionally, when you throw an error, you often pack the error object with clarifying information that will help the supervisors understand what was happening when the error occured. Again, this might be too much for a lower level function to handle. Pass the error up the chain and let a specialist handle the error.

2      

@boat  

Thank you both @Hatsushira and @Obelix.

yes , error throwing is quite technical and the syntax is complicated. That's why I've been procrastnating on it. Guess I will need to cross that bridge eventually.

@Obelix, please don't delete your example this time ;-p, I was trying to re-read the baking house example on return, and found out it was gone. I was quite sad T_T. Probably in the future you could publish a book called "Obelix's house of examples" , I will be first in line for autograph.

Take care fellows ~

2      

Hacking with Swift is sponsored by RevenueCat

SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure your entire paywall view without any code changes or app updates.

Learn more here

Sponsor Hacking with Swift and reach the world's largest Swift community!

Archived topic

This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.

All interactions here are governed by our code of conduct.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.