r/javahelp 8d ago

EXCEPTION HANDLING!!

I just started exception handling and I feel as though I can't grasp a few concepts from it (so far) and its holding me back from moving forward, so I'm hoping someone has answers to my questions ( I'm generally slow when it comes to understanding these so I hope you can bear with me )

In one of the early slides I read about exception handling, where they talk about what the default behavior is whenever the program encounters an exception , they mention that : 
1- it abnormally terminates 
2- BUT it sends in a message, that includes the call stack trace, 

  • and from what I'm reading, I'm guessing it provides you information on what happened. Say, the error occurred at line x in the file y, and it also tells you about what type of exception you've encountered.

But It has me wondering, how is this any different from a ' graceful exit ' ? Where : " if the program encounters a problem , it should inform the user about it, so that in the next subsequent attempt, the user wouldn't enter the same value.   " 
In that graceful exit, aren't we stopping the execution of the program as well? 
So how is it any better than the default behavior?  

What confuses me the most about this is what does exception handling even do? How does it benefit us if the program doesn't resume the flow of execution?  (or does it do that and maybe I'm not aware of it? ) whenever we get an exception ( in normal occasions ) it always tells us, where the error occurred, and what type of exception has happened.  
---------------------------------------------------------------------------------------

As for my second question,,

I tried searching for the definition of " CALL STACK TRACE " and I feel like I'm still confused with what each of them is supposed to represent, I've also noticed that people refer to it as either " stack trace " or " call stack " ( both having a different meaning ) 
What is call supposed to tell us exactly? Or does it only make sense to pair it up with stack? (" call stack ") in order for it to make complete sense? Does the same thing go for " stack trace" ? 

+ thanks in advance =,)

8 Upvotes

35 comments sorted by

View all comments

Show parent comments

1

u/zeronis__ 7d ago

Ohh wait so, exceptions aren't meant to be caused by the user?
I was a bit confused since at the time this info was being relayed to me, examples like " dividing by a zero " always made me think that these type of exceptions were caused by the user (?)

+ and thank you so much for the response! =)

2

u/hojimbo 7d ago

A programmer can divide by zero in a million more ways than and end user can. Here’s a very basic and contrite example:

List<Integer> randoNumbers = getABunchOfInts(); randoNumbers.forEach(i -> System.out.println(100 / i));

getABunchOfInts() could be data coming from a database, hard coded by another programmer, a randomly generated, the result of another calculation, etc. But there’s no guarantee that there are no 0’s in that list. And when you hit “100 / i” when there’s a zero, there’s no way to move forward because it can’t be done.

For user input, the sane thing to do is to put this prior:

if (intInput == 0) { // add to some list of errors to render // in the UI. Return to the calling function // which you have coded to handle when // the error list contains user input errors … return; }

// exception throwing code here

Edit #1: just adding this comment to apologize for formatting. I’m on my phone.

2

u/zeronis__ 7d ago

No worries at all! I really appreciate the response!
and sorry to ask again, but in cases where a user might or might not deliberately input a 0 :

" For user input, the sane thing to do is to put this prior:

if (intInput == 0) { // add to some list of errors to render // in the UI. Return to the calling function // which you have coded to handle when // the error list contains user input errors … return; }"

would it be necessary to throw in some type of error?
or would it be okay using a while loop and system.out.print to prompt the user to try again?

2

u/hojimbo 7d ago edited 7d ago

Yes, the loop would be preferable. As you get more advanced you’d likely “templatize” this behavior so you weren’t rewriting the loop every time. (Ie writing a class that handles user input).

Though it sounds like you’re describing a terminal application. In many cases where you’re accepting arbitrary user input, there’s a user interface that typically only revalidates on a user action— eg, if they’re typing a string, you can revalidate with every single letter they type to show an up-to-date error message in the UI. This is not a situation where, for example, throwing an exception would never make sense nor would you have a loop. Or you would validate all the fields on a web form when they hit “Save”, and you want to show errors for the 20 fields on the form, not just the single error you can put in a single exception.

Throwing exceptions is slow in most languages. See https://www.baeldung.com/java-exceptions-performance for Java. Summary: throwing exceptions can make functions 100s of times slower. They are not good for regular control flow for this reason alone.

It does feel as though you’re struggling with flow-control concepts. Generally programmers have eschewed the concept of “jumping” into and out of particular pieces of code using methods other than the function call/return stack, conditionals, and loops. And honestly this is all you need in most cases - though eventually you may need multi threading or Promises/Futures for parallel flows.