[1.12.2] Entity hands not rendering via an inventory

[Issac29]

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

[Draco18s]

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.

 

  On 12/27/2019 at 8:36 PM, Issac29 said:

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

Expand  

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.

Expand  

 

Edited December 27, 2019 by Draco18s

[Issac29]

So try and catch isn't reliable.

[DavidM]

  On 12/28/2019 at 2:23 AM, Issac29 said:

So try and catch isn't reliable.

Expand  

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, 2019 by DavidM

[Issac29]

  On 12/28/2019 at 12:20 PM, 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.

Expand  

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.

  On 12/28/2019 at 4:21 AM, DavidM said:

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

Expand  

Well not true.

 

Well this is getting well off topic.

[DavidM]

  On 12/28/2019 at 10:27 PM, Issac29 said:

Well not true.

Expand  

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.

[Draco18s]

  On 12/28/2019 at 10:27 PM, Issac29 said:

Well not true.

Expand  

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.

[Issac29]

  On 12/28/2019 at 10:27 PM, Issac29 said:

Well this is getting well off topic.

Expand  

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

  Quote

Entity hands not rendering via an inventory

Expand  

Where do the custom packets used at.

[Issac29]

  On 12/29/2019 at 4:57 PM, diesieben07 said:

Where do the custom packets used at.

Expand  

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

[Issac29]

So IMessage is the replacement or a substitution for IPacket.