Thanks for making us understand the important points so easily and on point concept. I have been studying from your video from a while and I must admit you make best video and your explanations are on point rather than unnecessary elaboration . Keep going and we need such tutorials almost everyday. Please make it more often so that more topics are covered. Good work brother 👏🙏
Thank you for taking time and writing this comment Shanu it means so much to me. Also one more thank you coz I think its time for me to create one more video on error handling because there are few updates in Swift and now there are couple of things we can do more
can we use multiple try to check both age and petrol quantity in same do try catch block or how can we check both age and petrol quantity or we need to do separately
very nice bro.. make one more video on it.. party 2.. How to do it in professional way.. and tell also about ... form validations like email password etc ..
Hello KarmJeet welcome to the channel, am glad this video was helpful, that's a great suggestion and also in my recent core data videos I been talking about how to do this validation so I will make a clean implementation of validation as well. If you have any questions then please feel free to ask and do share this channel with your iOS group on whatsapp or facebook
this multiple catch methods is working fine in playground. but not working this same method in xcode . check it once. *'catch' block is unreachable because no errors are thrown in 'do' block*
isko hm catch ki bjae ayse ki trah kr skte hn switch ( error) { case .network(let reason): //print reason case .server(let reason): //print reason case .respose(let reason ) //print reason } enum NetworkServiceError: Error{ case server( reason: String) case network(reason: String) // and so on }
Correct that's one way of handling it, here's my thought Our code base should NOT be surrounded by multiple catches and switch error cases. If your code is surrounded by lots of catch statement then that's defensive coding. You are allowing the system to fail when you pass a bad value but I want to ask that if you can catch the bad value before even it hits the source of data to me that's being proactive and making sure circuit failures in your code are avoided. I am not a big fan of multiple try catches or switch statements to be honest because if the code has multiple catches on a single do..try then to me that's a code smell and an area of improvement.
jb me api call krta hu response me mujh error type detect krni he .. github.com/nvdmcs/MyExperiments/blob/master/AalmofireJsonExample/AalmofireJsonExample/UserAPIManager.swift
I saw that repo and there are area of improvements like the usage of generics can be improved to just pass a type and not an array, well I left a bug for you where I want you to explain me why are you using a alamofire to make a simple api call coz the same can be done via URLSession. :)
Let me ask a counter question, what will you do after detecting the response? Do you plan to show the response to the user? We should never be displaying any technical messages to the user because for a user 404 Not Found or 500 Internal server error does not make any sense to them.
@@CodeCat15 some time hm me ne screen p error msg dekhana hota with icon . network, server r response ... in teeno ke icone kesy dikhae gy error type k hisab se? .. islye mujh error type detect krna zroori lg raha tha
alpha junnon my answer to that is with a question why do you want to show a technical response to a user? I would say just keep it simple, error messages to the user should be simple and a technical response. Look at all the big apps where have you seen a technical error message no matter what happens in the background their error message will always be simple.
Thanks for such a clear explanation, Ravi.
Thanks for making us understand the important points so easily and on point concept. I have been studying from your video from a while and I must admit you make best video and your explanations are on point rather than unnecessary elaboration . Keep going and we need such tutorials almost everyday. Please make it more often so that more topics are covered. Good work brother 👏🙏
Thank you for taking time and writing this comment Shanu it means so much to me. Also one more thank you coz I think its time for me to create one more video on error handling because there are few updates in Swift and now there are couple of things we can do more
thanks for such a easy to understand explain.
I think I will make one more on error handling, coz there are new ways you can handle error in the latest version of Swift.
Nice tutorial for beginner's
Am glad you liked it
can we use multiple try to check both age and petrol quantity in same do try catch block or how can we check both age and petrol quantity or we need to do separately
yes you can, or you can just throw an error when anyone of those fail, it depends on the need of the use case
very nice bro.. make one more video on it.. party 2.. How to do it in professional way.. and tell also about ... form validations like email password etc ..
Hello KarmJeet welcome to the channel, am glad this video was helpful, that's a great suggestion and also in my recent core data videos I been talking about how to do this validation so I will make a clean implementation of validation as well. If you have any questions then please feel free to ask and do share this channel with your iOS group on whatsapp or facebook
thanx, brother... your work very appreciable
welcome to the channel Sachin, I am glad this video was helpful please do share it with your iOS group and feel free to ask questions
this multiple catch methods is working fine in playground. but not working this same method in xcode . check it once.
*'catch' block is unreachable because no errors are thrown in 'do' block*
very good explanation!!!
thank you :)
Sir, I have a doubt, can we also use error handling for validations?
Can you elaborate that please
isko hm catch ki bjae ayse ki trah kr skte hn
switch ( error) {
case .network(let reason):
//print reason
case .server(let reason):
//print reason
case .respose(let reason )
//print reason
}
enum NetworkServiceError: Error{
case server( reason: String)
case network(reason: String)
// and so on
}
Correct that's one way of handling it, here's my thought
Our code base should NOT be surrounded by multiple catches and switch error cases. If your code is surrounded by lots of catch statement then that's defensive coding.
You are allowing the system to fail when you pass a bad value but I want to ask that if you can catch the bad value before even it hits the source of data to me that's being proactive and making sure circuit failures in your code are avoided.
I am not a big fan of multiple try catches or switch statements to be honest because if the code has multiple catches on a single do..try then to me that's a code smell and an area of improvement.
excellent
Thanks, plz do ask questions on the topic and do feel free to share this channel with your iOS group
jb me api call krta hu response me mujh error type detect krni he ..
github.com/nvdmcs/MyExperiments/blob/master/AalmofireJsonExample/AalmofireJsonExample/UserAPIManager.swift
github.com/nvdmcs/MyExperiments/blob/master/AalmofireJsonExample/AalmofireJsonExample/ViewController.swift
I saw that repo and there are area of improvements like the usage of generics can be improved to just pass a type and not an array, well I left a bug for you where I want you to explain me why are you using a alamofire to make a simple api call coz the same can be done via URLSession. :)
Let me ask a counter question, what will you do after detecting the response? Do you plan to show the response to the user? We should never be displaying any technical messages to the user because for a user 404 Not Found or 500 Internal server error does not make any sense to them.
@@CodeCat15 some time hm me ne screen p error msg dekhana hota with icon . network, server r response ... in teeno ke icone kesy dikhae gy error type k hisab se? .. islye mujh error type detect krna zroori lg raha tha
alpha junnon my answer to that is with a question why do you want to show a technical response to a user? I would say just keep it simple, error messages to the user should be simple and a technical response. Look at all the big apps where have you seen a technical error message no matter what happens in the background their error message will always be simple.