[Solved] [1.12.2] How to handle exceptions in constructors

[IceMetalPunk]

I have a class that extends Block. It also has composed in it a different, generic, class: OreDictManager. So in other words, the structure is basically this:
 

public class BasicBlock extends Block {
    private final OreDictManager<Block> oreDictManager;
}

I'm actually instantiating the new OreDictManager<Block> in the BasicBlock's constructor; the OreDictManager's constructor takes "this" as a parameter to bind the two together.

But here's the problem I'm having: the OreDictManager can manage either Block or Item classes. I don't want it to be able to be called with any other type. I couldn't find a way to have a Java generic that could take only two different classes which don't share a common ancestor, so instead I'm explicitly checking if the passed in argument's class is assignable from Block or Item, and throwing an exception in the OreDictManager's constructor if not.

My mod will be adding several BasicBlock instances to a list, but if any of them throw an exception upon instantiation, they shouldn't be added to the list. So what I figured was I'd just allow the exception thrown in OreDictManager's constructor to bubble up through BasicBlock's constructor, and in the registry code that adds the blocks to a list, just put a try/catch around the instantiation and list-adding.

But that's the problem: I don't know if this is the right approach. If I do this, there would be no code in the catch block, as I simply want the BasicBlock that failed instantiation to just not be added to the list. On the other hand, a try without a catch feels a bit like a bad habit.

What's the best way to handle this?

Edited August 8, 2018 by IceMetalPunk
Added [Solved] to title

[Cadiboo]

Both block and item extend IForgeRegistryEntry if that helps

[IceMetalPunk]

1 minute ago, Cadiboo said:

Both block and item extend IForgeRegistryEntry if that helps

Unfortunately, so do a ton of other things besides blocks and items, which shouldn't be supported. So I'd still need to do the explicit check as I'm doing now if I used that.

[Draco18s]

Only do items and handle blocks if they are ItemBlock?

[IceMetalPunk]

11 minutes ago, Draco18s said:

Only do items and handle blocks if they are ItemBlock?

Hm... Looking back at my code, I may be able to make it work with just ItemStacks instead... and only Items and Blocks can be passed to an ItemStack's constructor, right? So that'll at least move the burden of exception handling onto the code instantiating the OreDictManager rather than anywhere else... I'll try that and see if it looks cleaner...

*EDIT* Wait, no, shoot. One reason I went with templating was so that the OreDictManager's methods could return the original object, for method chaining. I can't do that if it's not actually templated...

Edited August 7, 2018 by IceMetalPunk

[Animefan8888]

34 minutes ago, IceMetalPunk said:

Unfortunately, so do a ton of other things besides blocks and items, which shouldn't be supported. So I'd still need to do the explicit check as I'm doing now if I used that.

I dont see why this is a problem actually, are you the only one using this code? If so then you should know that the only two types it can accept are Blocks and Items.

Ultimately you could make two classes that extend your OreDictManager that explicitly uses Item and Block respectively and possibly make your OreDictManager abstract unless there won't be a difference between the two functionally.

[IceMetalPunk]

9 minutes ago, Animefan8888 said:

I dont see why this is a problem actually, are you the only one using this code? If so then you should know that the only two types it can accept are Blocks and Items.

Ultimately you could make two classes that extend your OreDictManager that explicitly uses Item and Block respectively and possibly make your OreDictManager abstract unless there won't be a difference between the two functionally.

For now, yes, but I may allow IMC-based registration for other mods in the future. And the two have identical functionality, but because they (a) need to return the bound object from some methods and (b) call ore dictionary methods which exist only for Items and Blocks... well, you see the problem.

I suppose I could just make two different classes that are identical except for the data types that those particular methods return/use... that seems like a ton of repetition, though, and I was always taught that the DRY approach is the best, for various reasons.

 

*EDIT* A little more background about what this OreDictManager does: I'm using it so that blocks and items can supply ore prefixes and suffixes, and every combination will be registered automatically for them. So for instance, if I wanted an item to be registered as nuggetIron, nuggetFerrous, coinIron, coinFerrous, shardIron, and shardFerrous; rather than registering all those manually, I could just register the prefixes "nugget", "coin", and "shard" with the item's OreDictManager, and the suffixes "Iron" and "Ferrous", and all combinations will be registered automatically when appropriate. So I could use something like this:
 

this.oreDictManager.registerSuffixes("Iron", "Ferrous");
this.oreDictManager.registerPrefixes("nugget", "coin", "shard");

Wouldn't even have to make any calls to the OreDictionary itself, as the manager handles that.

Edited August 7, 2018 by IceMetalPunk

[Animefan8888]

4 minutes ago, IceMetalPunk said:

For now, yes, but I may allow IMC-based registration for other mods in the future. And the two have identical functionality, but because they (a) need to return the bound object from some methods and (b) call ore dictionary methods which exist only for Items and Blocks... well, you see the problem.

Force them to use a Block or Ite instance then you can limit that by making methods that add them, but only take a Block or an Item.

 

5 minutes ago, IceMetalPunk said:

I suppose I could just make two different classes that are identical except for the data types that those particular methods return/use... that seems like a ton of repetition, though, and I was always taught that the DRY approach is the best, for various reasons.

Hence why I said

10 minutes ago, Animefan8888 said:

you could make two classes that extend your OreDictManager

And make the constructor of the OreDictManager be protected so only classes extending it or in the same package can access instances of it. 

[Cadiboo]

Have a look at my solution to this problem at https://github.com/Cadiboo/WIPTechAlpha/blob/master/src/main/java/cadiboo/wiptech/util/ModEnums.java (ModMaterials)

all my metals are registered here with properties (hasOre, hasNugget, hasTools etc.) and registration is done automatically based on this. It’s even possible for other mods to add, remove & modify the materials

Edited August 7, 2018 by Cadiboo

[IceMetalPunk]

17 minutes ago, Animefan8888 said:

Force them to use a Block or Ite instance then you can limit that by making methods that add them, but only take a Block or an Item.

 

Hence why I said

And make the constructor of the OreDictManager be protected so only classes extending it or in the same package can access instances of it. 

...I think I misread your original post >_< . I also have no idea why I didn't think of using a protected constructor with inheritance... that would probably be the best way to do this! Thank you! I'll be implementing it tomorrow-ish, as it's late here, and then I'll post with the results.

[Animefan8888]

My bad sent this as I received your message.

Edited August 7, 2018 by Animefan8888
Removed for uselessness.

[IceMetalPunk]

Aaaannnddd it worked It also gave me an opportunity to refactor the way I was designing these classes in the first place, break them out into a common "api" package, etc. Thank you for your help, @Animefan8888!