Better understanding

[rigid urchin]

I wanted to get some better understanding by this statement and the code that follows with it.

This will make it so that calling code needs to check for the possibility of that exception being thrown.

int divide(int x, int y) throws Exception {
    if (y == 0) {
        throw new Exception();
    }

    return x / y;
}

void doStuff() {
    divide(1, 0);
}

Is it my understanding that "checked" just means that depending on the Exception given that if used elsewhere we need to also ensure that the Expection used is also thrown in the supporting methods/functions?

So something like throws Exception needs to also be added to doStuff() in this case but if this was a RuntimeException it would only need to be handled on the method/function that has a chance of causing the RuntimeException?

-- Edit --
As I moved onto Propagating Exceptions I think it makes more sense now what is occuring.

[tawny widget]

<@&987246399047479336> please have a look, thanks.

[warm pine]

Checked Exceptions (anything not an Error or RuntimeException or subclass) are compile time checked. That is the distinction. You're forcing the user of the method that might throw the exception to explicitly deal with it (wrap with try/catch). There's been a rather undue amount of pearl clutching regarding checked exceptions over the years but they do have a purpose when your building a system that needs to be resilient.

The runtime exceptions are mostly due to programming errors and not whatever logical specification you're trying to build.

[rigid urchin]

Ok, I think I comprehend it a bit more. So the best example I can think of would be if I am trying to communicate with a server, the server MIGHT give me a 404 error or sometype of error so the Checked Exception is there to prevent the entire program from crashing and will handle the possibility of that error. While a RuntimeException or subclass would just happen due to some sort of code error? Like not saying a method returns a boolean and instead it returns a String, sort of thing?

[warm pine]

Things where it's not feasible to continue with the current task but it's possible something else can be done to salvage the situation are good examples of where checked exceptions are used. Networking, I/O, interfacing with a peripheral like printer or whatever. Corrupted file, maybe the text has malformed unicode. The option of being able to do something else is given by the exception call out, even though when handling the exception at runtime, there may be limitless possibilities one would have to check, some line in the sand is drawn by the exception handler to only do so much.

I find checked exceptions are good when implementing some known spec or binary protocol.

[rigid urchin]

Ok I understand now, thank you for giving me a better insight on this. The "Checked" vs "Unchecked" exceptions was not fully registering until now. This clears things up a lot!

[ember forge]

checked vs unchecked doesnt change anything in ur actual logic

it behaves the same way

its just that with a checked exception the compiler forces u to think about "what if?"

whereas with an unchecked it doesnt do that and its optional

regardless of what the exception is, u always have 2 ways to deal with exceptions:

1. u handle it. try-catch
2. u forward the problem to ur callers/users. throws

with unchecked exceptions ur allowed to not do any of that

with checked exceptions ur forced to do 1. or 2.

either case, if an exception remains uncaught until it runs out of the code-flow (usually the main method), the program crashes

so even with checked exceptions, for example if u always decided for option 2., ur program will eventually crash

as to when u should design ur own exceptions to be checked or unchecked... well, its a bit of a controversial topic but what joe explained applies

(on the technical end in java, unchecked exceptions are the ones that inherit from RuntimeException, any other exception is "checked")

[warm pine]

If you look at the javadocs for the methods in List, you'll see a lot of methods call out the unchecked exceptions that it will throw for procedural errors like indexOutOfBounds. These are errors that nobody wants to force you handle because they pretty common if you've simply wired things up wrong.

[hard furnace]

And they won't happen if you've wired things up right... Whereas a FileNotFoundException can occur no matter your best efforts

[ember forge]

while thats the original intention its still a bit controversial. like, many people just hate checked exceptions in practice bc they are cumbersome to work with.
giving birth to commonly accepted "antipaterns" such as

try {
  foo();
} catch (IOException e) {
  throw new UncheckedIOException(e);
}

but that topic is now about whether u should choose checked or unchecked for ur own exceptions

and less about how the system works and how u, as user, have to work with it

[rigid urchin]

To be clear when you say callers/users this could be the physical user through some sort of input or even just the supporting methods/functions that are calling the method/function in question correct?

void doSomething(int value) throws Exception {
  if (value == 1) {
    throws new Exception();
  }
  return value * 2;
}

void doSomethingElse() { // This is the caller?
  return doSomething(2) * 2;
}

So its now up to the doSomethingElse function to handle the Exception or continue to propogate it up correct?

[hard furnace]

They're cumbersome due to the language - and Brian Goetz has been teasing some thoughts on improvements (aside from the pattern handling)...

Their purpose is fine. People say "only Java has this silly idea" but keep in mind that in languages like Rust (where errors are returned as values), every error is essentially a checked exception (since you can't even write code to get the actual return value without saying what you're doing with the error).

So generally...

Checked exceptions are for cases where the programmer cannot avoid the situation and can do something about it (eg a retry, substituting a default, or taking some other action).

Runtime exceptions for everything else. Java itself has sometimes made the wrong choice here.

[ember forge]

yes, doSomethingElse uses doSomething, and Exception is a checked exception. so the compiler now forces doSomethingElse to pick between 1. or 2.

so they can now either try-catch the call

or they can declared throws Exception themselves as well

forwarding the problem to its own users/callers

[rigid urchin]

I see, this is all coming together!

[ember forge]

if u continue picking option 2. all the way u eventually end up in the main method

and if u pick option 2. for main as well...

public static void main(String[] args) throws Exception { ... }

then u run into this statement:

if any exception (checked or unchecked, doesnt matter) runs out of the context (typically main method), the program crashes

[rigid urchin]

Then the program would just crash because nothing can handle it after that? Given this statement earlier?

if an exception remains uncaught until it runs out of the code-flow (usually the main method), the program crashes
so even with checked exceptions,

[ember forge]

👍

yeah, no one decided to actually catch the exception

so program goes boom

[rigid urchin]

Fantastic, this clears things up. Gives some control to the callers/users when an error occurs