Are there seriously neither of them in categories 1, 2, nor 3. 

For reference, that list came from here:

https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/

Note that Vexing is for things like int.Parse(str) that throws an exception when str isn't a valid integer (so use int.TryToParse(str) instead), but Java doesn't have a non-exception throwing version, hence, vexing.

 

Someone, somewhere, made a design decision to throw an exception and now you have to deal with it.

 

1 hour ago, Issac29 said:

1. what about runtime, null pointer, arraystore, array out of index, and index out of bounds.

Null check first, you bonehead.

Check your types first, you bonehead.

Check your bounds first, you bonehead.

Quote

...these are all problems that you could have prevented very easily in the first place, so prevent the mess in the first place rather than trying to clean it up.

 

Edited December 27, 20195 yr by Draco18s

So try and catch isn't reliable.

1 hour ago, Issac29 said:

So try and catch isn't reliable.

There is simply no need for try and catch. Try and catch should not be used as a fix for bad coding.

Edited December 28, 20195 yr by DavidM

10 hours ago, diesieben07 said:

Absolutely not true. If you tell Java to catch an exception, it will be caught. What we said above has nothing to do with reliability of try-catch.

Well for the useless number 4 exceptions. also known as the unnecessary exceptions which doesn't throw a compile error, unlike IO exceptions which do throw a compile unless there is a try and catch or a "throws" statement.

18 hours ago, DavidM said:

There is simply no need for try and catch. Try and catch should not be used as a fix for bad coding.

Well not true.

 

Well this is getting well off topic.

1 hour ago, Issac29 said:

Well not true.

In program design in languages like Java, try and catch should be avoided "at all costs".

To illustrate, this:

if (foo instanceof Bar) {
	Bar baz = (Bar) foo;
}

is much and always superior to this:

try {
	Bar baz = (Bar) foo;
} catch (ClassCatchException e) {
	// Do stuff.
}

both performance-wise and readability-wise.

Unlike some dynamic languages nowadays which greatly encourage try-catch over anything else (*cough* python *cough*), try-catch carries special connotation in languages like Java, and should not be used to 1) silence an unexpected error 2) fix bad coding.

Your usage of try and catch fall under both of those category, so in your case, there is no need for try and catch.

2 hours ago, Issac29 said:

Well not true.

Very much true.

I have first hand experience on just how costly a try-catch block is. I had code at one point that had the possibility of generating an error (a Vexing type) and wrapped it in a try-catch--because that was the right things to do. And the code was called so often that it ground Minecraft to a halt. We're talking two minutes per tick levels of slow for what was a few tens of thousands of calls.

 

Performing bounds-checks and null-checks on the other hand takes nano seconds, virtually zero time.

 

 I ended up just letting the exception be thrown and bypassing the compiler's check for exception handling, as it was an exception that could never occur unless something went very wrong indeed (better to let the game crash than catch the exception).

 

Code correctly and don't catch boneheaded exceptions. Boneheaded exceptions are the result of bugs. Don't intentionally hide bugs in your code.

2 hours ago, Issac29 said:

Well this is getting well off topic.

Although those unnecessary tries and catches, we might be getting too off topic with this title.

Quote

Entity hands not rendering via an inventory

Where do the custom packets used at.

47 minutes ago, diesieben07 said:

Where do the custom packets used at.

The interface IPacket. If a class implementing an IPacket then where does the it gets used for client networking?

So IMessage is the replacement or a substitution for IPacket.