In the last example presented by you ( that one with DoSomething and DoSomethingElse methods). If you re-throw the exception from the inner method ( DoSomethingElse) then why you rethrow it again in the higher method "DoSomething" in this way: " throw exception; " Should not be better just to use " throw; " . If you use just throw - then you can have the full track of all code spots when it was. And if you do it your way " throw exception" then you will loose full track of the exception - no information about line no.34.
great explination!! quick and to the point. but, I don't really see the point of the first exception you explained(1:57) (maybe that was also your point.) Because with or without it the end results will be the same; the run time will throw the exception whether your exception ask it to throw it or not.
@@CodeRadiance try statements take up a lot of resourse time. I'm not really sure how this "best practice" makes the code more clear; All it is telling me is that an exception may occur here so I am asking the compiler to do something it will do anyways. it would be just as clear (and more efficient) to make a comment saying that an exception might be thrown in this section of the code. if you actually wanted to do things according to best practices you should actually handle the exception.
Easy to remember: Exceptions vs Errors The engineer has to make sure that errors are handled even bevore they occur with the help of validations etc. Thatswhy "exceptions" should be seen as absolute exceptions. Something that the developer has not or can not foresee.
So fast sir . Its not easy to follow properly. This a important topic i think its better to explain such topics two videos. In that way viewer can get most out of it. great job. keep it up
Thank you so much for the wonderful explanation....saved me from the headaches
In the last example presented by you ( that one with DoSomething and DoSomethingElse methods). If you re-throw the exception from the inner method ( DoSomethingElse) then why you rethrow it again in the higher method "DoSomething" in this way: " throw exception; " Should not be better just to use " throw; " . If you use just throw - then you can have the full track of all code spots when it was. And if you do it your way " throw exception" then you will loose full track of the exception - no information about line no.34.
I think this video is very useful as an introduction to error handling, not necessarily a comprehensive guide to best practice. Thank you.
great explination!! quick and to the point.
but, I don't really see the point of the first exception you explained(1:57) (maybe that was also your point.) Because with or without it the end results will be the same; the run time will throw the exception whether your exception ask it to throw it or not.
Well at this point I think it's more about best practices and code clarity especially when there are overridden methods.
@@CodeRadiance try statements take up a lot of resourse time. I'm not really sure how this "best practice" makes the code more clear; All it is telling me is that an exception may occur here so I am asking the compiler to do something it will do anyways. it would be just as clear (and more efficient) to make a comment saying that an exception might be thrown in this section of the code. if you actually wanted to do things according to best practices you should actually handle the exception.
Easy to remember: Exceptions vs Errors
The engineer has to make sure that errors are handled even bevore they occur with the help of validations etc. Thatswhy "exceptions" should be seen as absolute exceptions. Something that the developer has not or can not foresee.
So fast sir . Its not easy to follow properly. This a important topic i think its better to explain such topics two videos. In that way viewer can get most out of it. great job. keep it up
I agree nice tutorial but you could slow it down slightly or use google 0.75 speed