I think the main point is that with exceptions you don't need lots of try-catch blocks all over the place. You only add them where they are relevant, while the rest of the code can be unconcerned with them, which isn't the case when you need to bubble up an error.
That is exactly my point. If I don't need to check/expect an error, I just don't do that and I know the program/thread will crash with a stack trace. If I don't have to write all the error handling and return them to the calling function, my code becomes cleaner and easier to read. Like in this example:
wait so you call functions that could throw exceptions but dont handle them until you find that they do throw? I was under the assumption you would still always check but would just prefer to do that check at a higher level (ie. wrap doJob in some error handling), but if you want to ignore errors just don't check them:
// assuming doNTask returns a string and an errorfuncdoJob()[]string{result1,_:=doFirstTask()result2,_:=doSecondTask()result3,_:=doThirdTask()return[]string{result1,result2,result3,}}
Of course, it is not that I totally ignore all errors/exceptions, I want to handle them (as you have written) "at a higher level". Probably also I don't always know all the exceptions that can be thrown.
And if I ignore an error like in your example, my program will continue to work i.e. all functions doFirstTask, doSecondTask and doThirdTask will be executed. I want my doJob function to fail after the first error. I can achieve that with panic but it is not a good solution too and not idiomatic.
Think of it like this: your code is made up of lots of functions calling lots of other functions that are calling lots of other functions. If something goes wrong somewhere, then it's not necessarily the function right above that one that's best placed to handle the error. A thrown exception allows the error to bubble up automatically until the level on which it makes sense to handle the error.
For example, if I have a complex algorithm that at some point does a division by zero, then the code calling the complex algorithm will need to e.g. use a fallback or notify the user of the error. In either case, it's not the algorithm function right above the error that is able to do anything useful with the division by zero error.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the main point is that with exceptions you don't need lots of try-catch blocks all over the place. You only add them where they are relevant, while the rest of the code can be unconcerned with them, which isn't the case when you need to bubble up an error.
I see what you mean, in cases where I don't want to check and wrap an error that would be convenient
That is exactly my point. If I don't need to check/expect an error, I just don't do that and I know the program/thread will crash with a stack trace. If I don't have to write all the error handling and return them to the calling function, my code becomes cleaner and easier to read. Like in this example:
wait so you call functions that could throw exceptions but dont handle them until you find that they do throw? I was under the assumption you would still always check but would just prefer to do that check at a higher level (ie. wrap
doJob
in some error handling), but if you want to ignore errors just don't check them:lmk if im not understanding you correctly
Of course, it is not that I totally ignore all errors/exceptions, I want to handle them (as you have written) "at a higher level". Probably also I don't always know all the exceptions that can be thrown.
And if I ignore an error like in your example, my program will continue to work i.e. all functions
doFirstTask
,doSecondTask
anddoThirdTask
will be executed. I want mydoJob
function to fail after the first error. I can achieve that withpanic
but it is not a good solution too and not idiomatic.Think of it like this: your code is made up of lots of functions calling lots of other functions that are calling lots of other functions. If something goes wrong somewhere, then it's not necessarily the function right above that one that's best placed to handle the error. A thrown exception allows the error to bubble up automatically until the level on which it makes sense to handle the error.
For example, if I have a complex algorithm that at some point does a division by zero, then the code calling the complex algorithm will need to e.g. use a fallback or notify the user of the error. In either case, it's not the algorithm function right above the error that is able to do anything useful with the division by zero error.