Order of exception handling

[bitter halo]

.

[dense path]

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

[dense path]

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

[bitter halo]

There's something which I was wondering baout exception handling and the order you'Re supposed to put them in : I understand there needs a specific order because of the types of the objects, but how is one supposed to know that object X is a subclass of another class? Going in the source code? Checking some online picture which shows the order of each class for error handling?

[warm sand]

Documentation I reckon should suffice in most cases

Your IDE might also show you a warning for dead code

[bitter halo]

you mean if i put the wrong order it will tell me

[warm sand]

Given that I haven't written a lot of java in the past year or two, I'm not entirely sure haha

[bitter halo]

wait really

how come

what do you code then

[warm sand]

I've been stuck doing more ops-y things

[bitter halo]

what does that mean

ops?

[warm sand]

Platform stuff rather than writing code

[bitter halo]

you mean on the graphical interface?

[warm sand]

Maintaining pipelines and openshift clusters

[bitter halo]

ok i have no idea what this is

btw random question

WHy is your username Seraphim?

Those are the baby angels right

[warm sand]

No, those are cherubim, idk how I came up with the name

I just wanted a name without numbers in them lol

[warm sand]

Regardless, this would be easy to test 😛

[bitter halo]

yes im going to do that jsut now

[warm sand]

Catch RuntimeException before any of the many derivatives

[bitter halo]

yes it give you a warning

[warm sand]

Like IllegalArgumentException

[bitter halo]

wait going to pictuer it

so it seems like there's no other way than checking online for the order by the looks of it

@warm sand Just wanted to confirm though, if I have different objects at the same level, the order here does not matte anymore, right

it's only when there's a risk of having a super class being put before its childs that this becoems a problem

[warm sand]

Correct, a class can only inherit from one other class 🙂

[bitter halo]

wait, no that's not what i meant

[warm sand]

As in, two sibling classes can never be interfering with each other

[bitter halo]

wait you seemed to have understood my question i think

ok so you agree with me then

[warm sand]

Yes haha

[bitter halo]

ah ok thanks

[autumn field]

Java can check at compile time that a catch block can never be reached if a prior catch block catches all the exceptions that would go into the later one:java try { something(); } catch (Exception e) { // Do something } catch (IOException e) { // This gives a compile-time error. // Do something }

[dense path]

Detected code, here are some useful tools:

[bitter halo]

yes, thats what i noticed with my error message

[autumn field]

Okay sweet.

[bitter halo]

btw do you have an answer for my original question

[autumn field]

Do you mean the original question in this thread?

[bitter halo]

so basically, i understand this hwole order thing, what i was wondering is how does one know the order, bascially searching for online pictures showing it? source code?

[autumn field]

The main way is basically just checking the source code. Typically, methods document what kinds of exceptions they throw, and usually someone can make an "educated guess" and then confirm what they know by checking the source code if they want. For example, FileNotFoundException is a subtype of IOException. Sometimes exceptions are named something blatantly more specific, so it's easy to tell, e.g. ArrayIndexOutOfBoundsException is a subclass of IndexOutOfBoundsException, which is fairly simple to see I guess.

Typically the programmer is expected to know the hierarchy though. The javadocs that are generated online are helpful with that (they list the class hierarchy for types), and during compile-time the IDE can usually check and tell you if you try to handle a checked exception that cannot actually be thrown from the try block.

Here's an example of the docs for IndexOutOfBoundsException: https://docs.oracle.com/javase/7/docs/api/java/lang/IndexOutOfBoundsException.html

Near the top, it lists the "Direct Known Subclasses" of the type.

[bitter halo]

oh ok, this makes sense. And like you said, in the very worst case scenario, my compiler will me if there's something wrong

so it's not that bad

Thanks again!

[autumn field]

You're welcome. :-)

[dense path]

Closed the thread.

[bitter halo]

re open

I forgot to ask something : when you say "thrown", you mean the process of creating an object of the type of the class

is my terminology correct here?

[autumn field]

Oh, no "thrown" means that an exception was used with the throw operator:java if (userInputIsBad()) { throw new IllegalArgumentException("That input is not valid!"); // This "throws" an IllegalArgumentException. }

[dense path]

Detected code, here are some useful tools:

[bitter halo]

but this creates an object here in your code no? ( i did not learn about this operator)

[autumn field]

The new operator creates a new object, but the throw operator causes the method to stop executing and to finish "with an exception." That exception will "propagate up" the call hierarchy until it is caught by a try-catch block:```java
void doSomething() {
try {
doSomethingElse();
} catch (Exception e) {
// An exception was thrown by doSomethingElse(), but we caught it.
}
}

void doSomethingElse() throws Exception {
throw new Exception("Example");
}```

[dense path]

Detected code, here are some useful tools:

[bitter halo]

so throw basically means that it stops your method and send you an error message?

[autumn field]

It stops the method, but it sends the caller an exception object (which is sort of like a message; it tells the caller what kind of issue occurred).

Exceptions are their own sort of beast. I'd like to find some resource that explains them in detail (there's a lot involved) but I don't know any off the top of my head haha.

[bitter halo]

It's ok, it's just my curiosity trying ot understand

unfortunaly, i have little time to do everything

[autumn field]

Why are you limited on time?

[bitter halo]

well, in school, you have to advance, regardless of your true understanding of something

[autumn field]

Oh, yeah. I understand that.

[bitter halo]

@autumn field Something which came to my mind : if I have a finally block, and for some reason my program had an exception to it which was no caught by any catch, if I understood correctly, my program will crash, but it will still execute the finally before crashing, right?

[autumn field]

Yes, the finally block gets executed after the corresponding try block completes, whether or not the try block completes normally (without throwing an exception, returning, or "jumping") or exceptionally (by throwing an exception, returning, or jumping).java void doSomething() { try { System.out.println("test"); return; } finally { // We get to this part as soon as the try part finishes, no matter how it finishes. System.out.println("This gets executed AFTER the return statement but BEFORE the method finishes."); } }

[dense path]

Detected code, here are some useful tools:

[bitter halo]

oh there's an implicit "return" statement here (did not learn about those"

anyway, thanks again for your help

you amaze me your knowledge

[autumn field]

You're welcome.

[autumn field]

And thanks. :)