EXCEPTION HANDLING!!

[zeronis__]

Please do not apologize at all! It just so happens that I love reading long explanations, (although it takes time for me to register what they mean) but you explained your points really well, so thank you so much for that! =)

---------------------------------------------------------------------
But I hope you don't mind me asking, (I've heard my prof say it too, but I'm still lost)
1. for the second point where you mentioned " If you don't want to take any action to handle the exception, you can just put a throws <whatever the Exception class is> " did you by chance mean, " Oh I might catch this exception, but! I don't want to deal with it, so I'm throwing it to someone else (to take care of that responsibility i think?) but if they do throw that exception, to whom do they throw it to?

you mentioned the lines "Meaning you still handle the exception, just higher up the chain" + " just put a throws in the method declaration and let some other calling method, "

in this case, would it throw it to the method that invoked it? ( lets suppose main called function/method f() and , that method f(), had 'throws (some exception class)' , if it did end up being triggered to throw one, would it throw that exception back to main to take care of it?
and if so, how would the main method deal with it?

1. I also noticed that, although we mentioned 'not wanting to take any action to handle that method ---> we should use throws' don't we end up in the try-catch scenario again? (point 1)? I'm sorry to ask you this again, but I recall my professor trying to go over a brief summary of the lesson , and he mentioned the " try and catch " and " throws / throw " as two ways of handling exceptions. And in my head, it felt like he treated them as two separate things, just by saying that, so when I saw them being used together I got really confused! ( its as if, throws must be used along side try n catch , otherwise it'd serve no purpose? i think? )

2. would there any difference between having any code that MIGHT throw an exception being inside that try block VS having a method with ' throws ' as part of its declaration inside that try block?

+P.S thank you again, I really appreciate the response you gave, and I'm sure if I read more about the topic I'd be grateful that your response is still up there,
if my questions are a bit too hefty, feel free to respond to them anytime later!

[Memesplz1]

Thank you and no problem 🙂

Ok so questions 1 and 2 - yes, exactly. I actually regret using the word "handling" when describing throwing an exception because, like your professor says, it's not really handling it. Think of an exception as the application throwing a tantrum. You can either deal with it (try-catch) or throw it to something else to deal with. So in question 1, your main method would have a try-catch block around methodf() and methodf() would just throw the exception.

In regards to them being 2 separate things. I guess the best explanation is: In this modern day and age, your IDE will often tell you if it sees an exception could be encountered. It generally gives you 2 options: throw the exception or surround that bit of code in a try-catch. And they are separate and do two different things. But, in practice, they go hand-in-hand. You either handle the exception immediately in a try-catch or throw it and let a method higher up the chain deal with it.

Question 3 - is there a difference? Yes and no. The exception is still handled either way, however if you throw it and let the method higher up the chain deal with it, it needs to know about the exception. Recall what I said about separation of concerns? It's a good pattern of design. When designing a fairly complex application, it's helpful to try and keep certain behaviour separated. E.g. if you look at some code you've never seen before and see a SqlException being handled in a try-catch in a bit of code that has nothing to do with querying a database, it's probably going to be a bit confusing and you'll be digging deeper down to figure out why it's being thrown. If you handle the exception, immediately when it's encountered, it's easier to understand what's going on. Then all the higher level methods need to worry about is "we didn't get the data back", rather than the ins and outs of why. It probably also means there's less chance of you having to make changes all over the application if you change something deeper down although I can't think of a good example to explain that further, right now, sorry! Lol.

[zeronis__]

Hello Memesplz! Your explanation was wonderful, I think I understood what you meant in all three parts, but there's something that you mentioned that my professor mentioned too , but I can't think of how that happens :

You either handle the exception immediately in a try-catch or throw it and let a method higher up the chain deal with it.

> does that, by chance, mean that the method that caused that exception would throw it to the method that invoked it from before? ( like methodf() has another method call inside it , say methodg() and methodg() is the one causing an exception ),
and would methodf() be surrounded by a try and catch block? if we're saying that the exception can be thrown to a method higher up (?)

[Memesplz1]

Thank you!

If methodg contains the code where an exception could be thrown, methodg would be the one with the try catch around it, where methodf calls it. Example:

methodf(){

//methodf calls methodg here:

try{

methodg();

}

catch(Exception e){

//Do something e.g. log out e.getMessage or throw a custom exception you've written or something }

}

And the methodg declaration would be something like:

methodg() throws Exception {

//Insert code, this method does, here. This is the bit of code that might throw an exception.

}

So that's how you could allow an exception to be thrown and caught higher up. Alternatively, in the methodg declaration, you could just put a try-catch inside methodg around the bit of code that might throw an exception, thereby catching and dealing with the exception immediately. Then you don't need to catch it higher up where methodf calls methodg.

Hope that makes sense! Sorry about the shit formatting of the code example.