I'm reading "Java All in One for Dummies," and I had trouble wrapping my head around the "throwing exceptions" chapter. Thank you for clearing up my confusion. Your lessons are intuitive and straight to the point. Your delivery is amazing.
Hi John, I recently discovered your channel, and I loved the way you expose the content. Learning to program when you are close to 50 years of age, is a much more affordable challenge with the help of channels like yours, thank you very much for your time and dedication. Greetings from Chile.
I appreciate your courage coz guys in 20's are finding hard to understand Java but you in your 50's have accepted this challenge to learn java at your age. I wish you all the best and I hope with your dedication and interest you will master it.
After going through several videos, this is the first truly informational one. No weird jumps, well-spoken English and not a lot of noise around the main topic. I know this video is old by now - but keep it up! :P
Hello John, thanks a lot for this video. I watched it some months ago and I missed some points you made about passing Throwable into the custom exception constructor but watching it again now made me realized how detailed this video is. Thanks a lot.
thanks john. I've been watching more and more of your videos as a java beginner, and as I watch them, each one makes me more certain to get your java bootcamp. these videos are truly great and if im going to learn even more, it will be immensely helpful to know the fundamentals are coming from you.
We should neither extend Throwable and nor use it in Catch block. Reason why not to use Throwable in catch block is that it will catch Error also which is not desired .
love the way you've explained this concept... I didn't learn this properly in C++ so ... I'm really happy that I could understand it so quickly... thank you so for that 😊
I think Streams are a little bit more complex than exception Handling. At least in Theory. But i would recommend u to write all existing Stream Classes down (Sub/Base Classes, Decorators, Reader/Writers,...) and put them in Relation.
How to know if an exception is checked (Compile Time ) or Unchecked (Run Time) Ans: If a class extends Exception ->It is known as Compile Time or Checked Exception If a class extends RuntimeException ->It is known as RunTime or Unchecked Exception
Great content. Please add the benefits of catching it in your catch block. Also point out that extending from IllegalArgumentException changes the custom to a runtime excpetion.
I found that mojang used exceptions very weirdly. If a network packet is in the wrong thread, they append it in a thread and basically throw a exception that does no logging to stop processing of said network packet. (Ignoring the implication on how bad it is to throw hundreds of exception per second, it is still a really interesting concept)
hey john this tutorial was so informative within a short duration you have covered many important topics! do you offer J2EE and spring related course? besides highfive to you that we have same name....
Could you show exception handling in possibly a larger code base? I understand the concepts but fail to put them into the big picture. For example why use an exception at all instead of an if statement since the possibility of getting a negative age is common .
Take for example a method that returns a number that is either valid or broken, how do you check that assuming you don't know what the method does? The method could have instead a BrokenNumberGeneratorException in the method and you could catch it
Mr John what do i need to become a software engineer just like you? meaning after learning java or any other language what are other things that i need to learn in other to become a software engineer.
Yep, new camera! Besides that part, it's pretty hard to tell the difference between this and all my other videos which were just recorded with a phone.
But at which point is it worth it to actually create your own custom Exception rather than just using (going by this example) IllegalArgumentException with a message that says something like "age must be positive". Would one ever put additional functionality in a custom Exception? Aside from the comedic value of hilariously named exceptions that your co-workers would hopefully run into (itWasYourJobToImplementThisException), why bother?
It is probably worth creating your own custom Exception when you can have actual value in using that type in a "catch". Maybe an example of potentially good "additional functionality" could be extra fields that store information that "catch" block could use. Like a MessageNotReceivedException could take a reference to the message so that the catch block can requeue it.
In many backend projects (say microservices with many inputs and outputs), I distinguish between client validation exceptions (invalid external input), upstream exceptions (like database failure), retryable exceptions and non-retryable exceptions. I then want every transaction to have exactly one and only one final status: happy (info) or one fatal exception (log error) type. No matter the service type, it's similar to HTTP or FTP response codes: 200 ok, 404 not found, different 4** client errors, and 5** (this service failed) or upstream/gateway temporary or unrecoverable failure.
Many projects decide whether to handle checked or unchecked exceptions exclusively on day one. Checked Exceptions should be handled immediately by the caller. If a project team (for whatever reason, including lack of discipline) won't consistently handle checked exceptions, then IMO the team should decide to wrap (all) checked exceptions as unchecked (either as a rethrown RuntimeException cause or custom exception extending some runtime exception). I recommend a strict consistent pattern, rather than developer whim ("hey this existing exception sounds kinda like it fits our problem"). If you're not sure, then wrap all exceptions as RuntimeException (or a single common custom exception) until you refactor later when/if you do know what you want.
Maybe it's worth noting that many, including architects at Sun, considered the combination of checked and unchecked exceptions a compromise and regrettable failed experiment. Checked exceptions help write reliable fail-proof code. But if not properly understood, not properly handled, checked exceptions often lead to terrible programming habits (like catch and ignore at worst to catch and rethrow at uh, typical annoying tedium). The Throwable, Error, Exception, RuntimeException inheritance structure is a (necessary?) bastardization that also encourages (allows for) poor coding practice (exception mis-handling).
Hi John, I have a quick question. Is it correct that if we use an unchecked exception, it is better to surround the exception block with try-catch instead of using throws in the method signature? However, if it is a checked exception, then it is better to use throws in the method's signature.
Extending Exception is usually a bad idea. Checked exceptions were a failed experiment and only leads to empty global catch clauses strewn through the code. Instead custom exceptions can extend RuntimeException. Furthermore throws clauses on methods are a pain in the ass when trying to pass method references.
Hello, thanks for a nice video. One point that I want to understand, do you think that validation should be handled by exception? As far as I know exception is quite heavy for JVM. Maybe better just return true or false in case something valid or not.
Thanks for the video. I'm just wondering: My instructor said regarding "error messages" => Especially with exceptions: Issue clear error messages! Cryptic Java messages about what is wrong where and how in the code are of no interest to the actual user of the program. How do you feel about this?
I'm trying to do unit tests of my project that has a custom exception class and it gives me an error that it triggers the custom exception (I want it to, that's the point of the test).
Depends on what you would like to print. sout(e) doesn't give you very much (I haven't tried it until just now, but looks like it just prints the class name of the exception). e.printStackTrace is often useful for debugging (although logging tools handle printing the stack trace for an exception their own way in larger applications), so that is more likely what you want. You can also print out the message on your exception if there is one, which you can find at myException.getMessage();
If you dont extend exception wouldn't a try catch block also not work if it were trying to catch all Exceptions? Since most exceptions inherit from a root parent Exception?
Is there an inherent overhead (performance degradation of the app) when using Exceptions and Custom Exception handling for "business" error handling as opposed to just putting in validations in code without exception handling? (Assume a large application with many business rules and just trying to come to terms with making a decision of when to use custom Exceptions for business validations vs never)
If you could actually watch over what I do when I'm bored, you would definitely murder me. I have made a class called ThisIsNotAnErrorOrAnExceptionButCanBeThrown that extends Throwable, and I have also made an anonymous inner class that is an exception.
By creating so many custom exceptions, wouldn't it be so unmanageable? Rather we use or define a little more generic or superclass of specific exceptions and pass in the details as param?
Thanks to Mailgun for sponsoring this video! Head to mailgun.com/john to try Mailgun free today.
If you have any questions, be sure to ask here!
Nice, you actually did a video for what i asked for. Youre the best, thank you!
I'm reading "Java All in One for Dummies," and I had trouble wrapping my head around the "throwing exceptions" chapter. Thank you for clearing up my confusion. Your lessons are intuitive and straight to the point. Your delivery is amazing.
We’ll done. You’re a natural teacher!
Hi John, I recently discovered your channel, and I loved the way you expose the content. Learning to program when you are close to 50 years of age, is a much more affordable challenge with the help of channels like yours, thank you very much for your time and dedication. Greetings from Chile.
I appreciate your courage coz guys in 20's are finding hard to understand Java but you in your 50's have accepted this challenge to learn java at your age. I wish you all the best and I hope with your dedication and interest you will master it.
if you hadn't explained the extends RuntimeException part, wouldn't have saved me in a pinch! Thank you so much!
After going through several videos, this is the first truly informational one. No weird jumps, well-spoken English and not a lot of noise around the main topic.
I know this video is old by now - but keep it up! :P
Watching this before exam, you're a great teacher.
that runtime stuffe just solved me a task i thought is difficult, thanks
I purchased your course, however, now i realized you have more detail knowledge on youtube
Hello John, thanks a lot for this video. I watched it some months ago and I missed some points you made about passing Throwable into the custom exception constructor but watching it again now made me realized how detailed this video is. Thanks a lot.
Before this video i was suffering with Exception but now i find it so easy thank you for your effort
ive been watching many of your video for the past 3 hours, youre an actual legend
i love your simple but clear explanations,,thanks John
thanks john. I've been watching more and more of your videos as a java beginner, and as I watch them, each one makes me more certain to get your java bootcamp. these videos are truly great and if im going to learn even more, it will be immensely helpful to know the fundamentals are coming from you.
i have already registered in his bootcamp but there is no problem solving exercices right there we can only watch tutoriels
Thank you for this well informed video. I was able to complete my assignment after watching it.
Brilliant teaching, every word you spoke in this video had intense meaning to it, Thank you
We should neither extend Throwable and nor use it in Catch block. Reason why not to use Throwable in catch block is that it will catch Error also which is not desired .
And thus passing Error to custom exception constructor should fail to compile. In other words: Exception cause, not Throwable cause.
I Agree there is really no need to extend Throwable.
Watched all videos...ur teaching style is awesome.....plz bring videos on Spring Boot
Yes, absolutely i am also waiting for Spring boot playlists
Thanks for your efforts in here… making complex things simple to understand. A request, please explain time and space complexities in your terms.
Thanks man.... I'm watching your video from India... it's really helpful
Simple, informative, and clear. Brilliant. Thank you!
Wish you have a full spring boot course!
Your Video always pop up whenever I needed the most! Thank you
I'm obsessed with your content, amazing job!!
useful content... but I don't like ads, and thanks for time stamps
Struggled with this topic for so long..... You're an amazing teacher 🙌🏻🙌🏻🙇♂️.... Thank you so much🙏🏻
love the way you've explained this concept... I didn't learn this properly in C++ so ... I'm really happy that I could understand it so quickly... thank you so for that 😊
Thank you for making all wonderful videos on Java!! All of them very clarifying!
Hey John!
Loving all your videos!
Could you do a tutorial on Streams? 🤩
Thank you so much!
I think Streams are a little bit more complex than exception Handling. At least in Theory. But i would recommend u to write all existing Stream Classes down (Sub/Base Classes, Decorators, Reader/Writers,...) and put them in Relation.
Can you make a video on collection framework. Loved the way you explain the concept.
Thanks sir 😊 That was helpful 🙂
I was having trouble making custom exception, Thanks to this video finally its done
Not so hard once you know!
Simple and clear explanation
How to know if an exception is checked (Compile Time ) or Unchecked (Run Time)
Ans: If a class extends Exception ->It is known as Compile Time or Checked Exception
If a class extends RuntimeException ->It is known as RunTime or Unchecked Exception
I'm so fortunate to see a java developer hailing from the last ice age :)
Great content. Please add the benefits of catching it in your catch block. Also point out that extending from IllegalArgumentException changes the custom to a runtime excpetion.
Wow, cleared some of my confusions, good stuff! Thank you so much John!
Thanks John! Helpful as always :)
Easy to understand! Will remember the *don'ts* 😂👍🏻
Amazing. You really helped me wrap my head around this concept. Thank you so much, I really appreciate it.
Looking forward to your hair sponsorship.
Your channel is gold wow!
What a simple way to explain things ! Thank's a lot. 😁😁
Have you ever considered making videos on data structures in Java? Thanks for the videos!
I found that mojang used exceptions very weirdly.
If a network packet is in the wrong thread, they append it in a thread and basically throw a exception that does no logging to stop processing of said network packet.
(Ignoring the implication on how bad it is to throw hundreds of exception per second, it is still a really interesting concept)
Thanks for your work
hey john this tutorial was so informative within a short duration you have covered many important topics! do you offer J2EE and spring related course? besides highfive to you that we have same name....
Thank you for another easy to understand video!
john john john, your videos are inspiring
Thanks, I thought exceptions were some magic, I didnt realise they were just classes.
Yeah I know what you mean, it feels like such a mystery until you learn that.
Thanks John
From Ukrainian dev with huge appreciation! / Від українського розробника з вдячністю!
Hi John! Thank's for your great tutos. Could you make a video on the binary search algorithm? Think it would be helpful. Thank's :)
Good video. Direct and amazing!
Great explanation.
Thnak You for this lecture.
Good to see you finally ditched eclipse 😛😛
Really helpful. Thank you sir.
throw new NullPointerException();
//shortcut for throwing a null pointer exception:
throw null;
I will find out..i have eyes 👀 everywhere
That's funny 😂
Well done
Hey John you are awesome
Hi, can you do a javaFX tutorial or perhaps a short video showing how to begin? Thank you : )
Thank you
Thank you .
Very good video
YES
Thank you!
thank you so much
Constructor takes Throwable or Exception cause?
I don't now how to thank you. GBU
Finally got it🎉
Could you show exception handling in possibly a larger code base? I understand the concepts but fail to put them into the big picture. For example why use an exception at all instead of an if statement since the possibility of getting a negative age is common .
Take for example a method that returns a number that is either valid or broken, how do you check that assuming you don't know what the method does? The method could have instead a BrokenNumberGeneratorException in the method and you could catch it
Mr John what do i need to become a software engineer just like you? meaning after learning java or any other language what are other things that i need to learn in other to become a software engineer.
I like the part where you point at the camera and go out of focus and then come back. That was very cinematic.
Yep, new camera! Besides that part, it's pretty hard to tell the difference between this and all my other videos which were just recorded with a phone.
Hi, Can you add a Maven tutorial? Thanks.
nice u a real goood teacher
Thanks :)
But at which point is it worth it to actually create your own custom Exception rather than just using (going by this example) IllegalArgumentException with a message that says something like "age must be positive".
Would one ever put additional functionality in a custom Exception? Aside from the comedic value of hilariously named exceptions that your co-workers would hopefully run into (itWasYourJobToImplementThisException), why bother?
It is probably worth creating your own custom Exception when you can have actual value in using that type in a "catch".
Maybe an example of potentially good "additional functionality" could be extra fields that store information that "catch" block could use.
Like a MessageNotReceivedException could take a reference to the message so that the catch block can requeue it.
@@stephenJpollei Ah right, I can see how that would be useful.
In many backend projects (say microservices with many inputs and outputs), I distinguish between client validation exceptions (invalid external input), upstream exceptions (like database failure), retryable exceptions and non-retryable exceptions. I then want every transaction to have exactly one and only one final status: happy (info) or one fatal exception (log error) type. No matter the service type, it's similar to HTTP or FTP response codes: 200 ok, 404 not found, different 4** client errors, and 5** (this service failed) or upstream/gateway temporary or unrecoverable failure.
Many projects decide whether to handle checked or unchecked exceptions exclusively on day one. Checked Exceptions should be handled immediately by the caller. If a project team (for whatever reason, including lack of discipline) won't consistently handle checked exceptions, then IMO the team should decide to wrap (all) checked exceptions as unchecked (either as a rethrown RuntimeException cause or custom exception extending some runtime exception).
I recommend a strict consistent pattern, rather than developer whim ("hey this existing exception sounds kinda like it fits our problem"). If you're not sure, then wrap all exceptions as RuntimeException (or a single common custom exception) until you refactor later when/if you do know what you want.
Maybe it's worth noting that many, including architects at Sun, considered the combination of checked and unchecked exceptions a compromise and regrettable failed experiment. Checked exceptions help write reliable fail-proof code. But if not properly understood, not properly handled, checked exceptions often lead to terrible programming habits (like catch and ignore at worst to catch and rethrow at uh, typical annoying tedium). The Throwable, Error, Exception, RuntimeException inheritance structure is a (necessary?) bastardization that also encourages (allows for) poor coding practice (exception mis-handling).
Hi John,
I have a quick question. Is it correct that if we use an unchecked exception, it is better to surround the exception block with try-catch instead of using throws in the method signature? However, if it is a checked exception, then it is better to use throws in the method's signature.
Thanks that was really usefull
thank you for th great videos
NegativeAgeException.
Even better!
God sent
Extending Exception is usually a bad idea. Checked exceptions were a failed experiment and only leads to empty global catch clauses strewn through the code. Instead custom exceptions can extend RuntimeException. Furthermore throws clauses on methods are a pain in the ass when trying to pass method references.
What VS Code theme is he using?
This is IntelliJ, with the standard theme. The only change is I darkened the background a little.
hi john ,can u pls make a video on java Streams api
why did our custom exception extend Exception? why not RuntimeException?
Hello, thanks for a nice video. One point that I want to understand, do you think that validation should be handled by exception? As far as I know exception is quite heavy for JVM. Maybe better just return true or false in case something valid or not.
exceptions (throwing and not throwing) have gotten lighter at least
Thanks for the video. I'm just wondering: My instructor said regarding "error messages" => Especially with exceptions: Issue clear error messages! Cryptic Java messages about what is wrong where and how in the code are of no interest to the actual user of the program. How do you feel about this?
I'm trying to do unit tests of my project that has a custom exception class and it gives me an error that it triggers the custom exception (I want it to, that's the point of the test).
Sir, How can we print the custom exception in catch block like e.printStackTrace() or sout(e);
Depends on what you would like to print. sout(e) doesn't give you very much (I haven't tried it until just now, but looks like it just prints the class name of the exception).
e.printStackTrace is often useful for debugging (although logging tools handle printing the stack trace for an exception their own way in larger applications), so that is more likely what you want. You can also print out the message on your exception if there is one, which you can find at myException.getMessage();
@@CodingWithJohn Thank you sir for replying for my message with a good explanation 😊
If you dont extend exception wouldn't a try catch block also not work if it were trying to catch all Exceptions? Since most exceptions inherit from a root parent Exception?
Is there an inherent overhead (performance degradation of the app) when using Exceptions and Custom Exception handling for "business" error handling as opposed to just putting in validations in code without exception handling? (Assume a large application with many business rules and just trying to come to terms with making a decision of when to use custom Exceptions for business validations vs never)
I did learn something. Namely, where those nasty 'caused by'-s come from.
You are awesome!!!!!
If you could actually watch over what I do when I'm bored, you would definitely murder me. I have made a class called ThisIsNotAnErrorOrAnExceptionButCanBeThrown that extends Throwable, and I have also made an anonymous inner class that is an exception.
I love MailGun, they just can't send the lower receiver.
By creating so many custom exceptions, wouldn't it be so unmanageable? Rather we use or define a little more generic or superclass of specific exceptions and pass in the details as param?
loved it
have anybody noticed the font colors in Intellij mach the Java logo colors?
can you put videos on jdbc?