[Not Solved!] Gui Null Error

Discussion in 'Plugin Development' started by PotatoLol12321, Nov 10, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    PotatoLol12321

    CentrumGuy, It still isn't working, I think its with the config because it works with out grabbing strings, but I print all the strings out, and they all work... So I'm not sure what's wrong with it. :/
     
  2. Offline

    CentrumGuy

    I think it's the .replace('&', '§') method. That always gives me a null pointer exception. Try using a try and catch and if that doesn't work try deleting the .replace(...) method
     
  3. Offline

    Rocoty

    How does no one see it? Seriously don't come with workarounds like null checks and try-catch because it can't and won't fix the problem of inv being null.

    PotatoLol12321 The reason inv is null is because you never initialise it. You might think you initialise it because you put initialisation in the constructor, but that constructor is actually never called. When you call the constructor by passing your main class instance, Java picks the one that fits the best to your arguments, i.e. The top one. The second one never gets called and thus the inv is never initialised.

    To fix this, do not declare two constructors. You don't need it. Move all the code from the second constructor into the first one and remove the second.
     
    CentrumGuy likes this.
  4. PotatoLol12321 it says "at org.bukkit.craftbukkit.v1_6_R3.entity.CraftHumanEntity.openInventory". This means, that the method "openInventory" is called on a pointer, which points to null.
    Code:java
    1. public void show(Player p) {
    2. if(inv!=null)
    3. p.openInventory(inv);
    4. }

    This will fix your problem. the exception won't be thrown anymore. If you wan't to know why your inventory is null, look at the hashcodes of the objects you are working on:

    Code:
    public void show(Player p) {
    System.out.println("Inventory when 'show' is called: "+inv);
    System.out.println("Menu-Hashcode: "+this.hashCode());
    if(inv!=null){
    System.out.println("Inventory-Hashcode: "+inv.hashCode());
    p.openInventory(inv);
    }
    }
    Code:java
    1. public Menu(Plugin p) {
    2.  
    3. inv = Bukkit.getServer().createInventory(null, 9, MenuInv.config.getString("GUIName").replace('&', '§'));
    4.  
    5. // Edited lines
    6. System.out.println("Inventory when Menuobject is created: "+inv);
    7. if(inv!=null)
    8. System.out.println("Inventory-Hashcode: "+inv.hashCode());
    9.  
    10. a = createItem(MenuInv.config.getString("Slot1.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot1.Item.ID"), MenuInv.config.getString("Slot1.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot1.Item.DataValue"));
    11. b = createItem(MenuInv.config.getString("Slot2.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot2.Item.ID"), MenuInv.config.getString("Slot2.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot2.Item.DataValue"));
    12. c = createItem(MenuInv.config.getString("Slot3.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot3.Item.ID"), MenuInv.config.getString("Slot3.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot3.Item.DataValue"));
    13. d = createItem(MenuInv.config.getString("Slot4.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot4.Item.ID"), MenuInv.config.getString("Slot4.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot4.Item.DataValue"));
    14. e = createItem(MenuInv.config.getString("Slot5.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot5.Item.ID"), MenuInv.config.getString("Slot5.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot5.Item.DataValue"));
    15. f = createItem(MenuInv.config.getString("Slot6.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot6.Item.ID"), MenuInv.config.getString("Slot6.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot6.Item.DataValue"));
    16. g = createItem(MenuInv.config.getString("Slot7.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot7.Item.ID"), MenuInv.config.getString("Slot7.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot7.Item.DataValue"));
    17. h = createItem(MenuInv.config.getString("Slot8.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot8.Item.ID"), MenuInv.config.getString("Slot8.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot8.Item.DataValue"));
    18. i = createItem(MenuInv.config.getString("Slot9.Item.Name").replace('&', '§'), MenuInv.config.getInt("Slot9.Item.ID"), MenuInv.config.getString("Slot9.Item.Lore").replace('&', '§'), MenuInv.config.getInt("Slot9.Item.DataValue"));
    19.  
    20. inv.setItem(0, a);
    21. inv.setItem(1, b);
    22. inv.setItem(2, c);
    23. inv.setItem(3, d);
    24. inv.setItem(4, e);
    25. inv.setItem(5, f);
    26. inv.setItem(6, g);
    27. inv.setItem(7, h);
    28. inv.setItem(8, i);
    29.  
    30. Bukkit.getServer().getPluginManager().registerEvents(this, p);
    31. }


    This code will print the hashcodes of the objects you're working on and the inventoryobject you are working on on the console. If the hashcode, which is print in the constructor, is not equals to the hashcode, which is print in the "show" method, you're working on two different objects.
     
  5. Offline

    Rocoty


    Sorry, no. Yes the exception will not be thrown anymore, but it does by no means fix the problem. Because the inventory still won't ever open because inv always points to null. Read my explanation above.
     
  6. Rocoty the problem is not that the inventory is null. This is the cause. The problem here is that openInventory is called on null. And this is fixed by a nullcheck. That the object is never created is just the cause. A problem only exists if the code can't run without throwing exceptions. I know what you want to say, but what i said is totally right. the problem is solved, but not by fixing the cause. it's no real workaround like you said, but it goes in this direction. Also if he/she would have executed the code, then print which is made in the constructor wouldn't have been made. This is called debugging :p he/she should lean it instead of getting spoonfeeded
     
  7. Offline

    Rocoty

    Shmobi Mostly agreeable. But I don't agree hiding the problem is a real fix, more of a workaround that will cause trouble later on. Much like catching and swallowing exceptions just to avoid a stack trace. Checking if the variable points to null does prevent a stack trace, but the problem is still present. That is, inv being null. Fixing the cause of the problem as you put it, will remove the need for a null check altogether, because you ensure inv is never null. And if inv is declared final, like it should be, then you can be 100% certain of that.
     
  8. Rocoty as long as createInventory(null, 9, MenuInv.config.getString("GUIName").replace('&', '§')) does not return null, you're right. If the config changes, "GUIName" will cause a problem. i don't know if it will throw an exception or if it will return null, but for safety you should always check for null. Like i already said... checking for null will fix the problem, but not the reason why the problem existed!! Also nullsafety is important, you should include it anyway
     
  9. Offline

    fireblast709

    Shmobi there are null checks, and there's hiding errors that should not exist, like Rocoty already mentioned. The OP's issue is part of the second. You are just creating a new bug.
     
  10. fireblast709 a bug is a not wanted "function" which is created through wrong code. this code does only what it shall do. if there is no inventory, do not show it. it is no bug, it is a wanted function. error solved, reason ignored. of course i'm ignorring the cause for the error as Rocoty says, but that's not the only thing i told him/her to do to fix the error. if he/she would've done everything what i told him, he/she would've recognized it by him/her self. what Rocoty did was spoonfeeding, just tell them why the error happens, but let them search where!!
     
  11. Offline

    Marcthecool

    Maybe it's your coding wrong. Recommend looking on YouTube or contact me on Skype: marc.johnson668
     
  12. Offline

    fireblast709

    Shmobi Rocoty spoonfeeding, that's quite a good joke. If you actually read the code instead of blindly giving bad advice, you would've known the code would only be executed with the reason to show the inventory. Confusing people doesn't teach them a thing, so of you decide you only want to sound smart, just don't post.
     
  13. Marcthecool the problem is already solved. it's just a "discussion" (if you're allowed to call this bullshit a discussion) with fireblast709 about "is nullsafety important and should you tell people where and why their code fails or should you rather just tell them why but let them search on their own"
     
  14. Offline

    fireblast709

    Shmobi if you want to call your bad argumentation a bullshit discussion, be my guest. I won't be silent when someone is handing out bad advice, and dares to look down on me for his own incompetence.

    "A man won't know how to fish (and thus be able to feed himself) if you don't teach him how to fish"
     
  15. fireblast709 i told him how to fish, i just don't told him where. that's something he has to find out on his own. As i already said, if you would've read my whole post, he would've been just fine by doing everything i told him. he would've found the error on his own and would've known how to understand the nullpointer exception. you're just telling him "change this and this and this and you're done, but don't ask why, because i won't tell you :p"
    And now please stop bumping this thread. if you want to discuss with me something that does not belong to this thread, you can contact me with a pn and i ll answer back asap
     
  16. Offline

    fireblast709

    Shmobi you told him to catch a whale with a small fishing rod. While you might be able to hook it, you will never get it ashore.

    Checking for null should only be done if the variable in question has a legitimate state where it can be null. This one does not. Forgetting to assign a variable is an actual error you should fix by assigning a value, and there's not much to explain why: you simply do because you want to use the bloody variable.

    That's today's lesson on how to fish: use the right tools for the right task.
     
  17. fireblast709 a) the method which is initializing the variable CAN return null and so you should insert a null check b) like i said (about felt 100000 times) READ THE WHOLE THREAD and you can see that i gave him the fishing rod he need to catch a whale
     
  18. Offline

    fireblast709

    Shmobi now go read the source and get off the thread. createInventory(...) will not return null. You told him to create a new bug, which is not how you help people.
     
  19. fireblast709 seems like we define the word bug differently. like i said, contact me personal if you want discuss, otherwise stop bumping this thread please, i will now, too
     
  20. Offline

    PotatoLol12321

  21. Offline

    fireblast709

    PotatoLol12321 you currently only have one constructor, which means either one (but not both) will be called. Move the code from the Menu(Plugin) constructor to the other one (and remove what remains of the Menu(Plugin)). That will execute all code you intend to execute (like assigning the inv field, to prevent the NullPointerException)
     
  22. Offline

    PotatoLol12321

    fireblast709 I'm still getting the error, I moved it to the Show(Player) constructor.
     
  23. Offline

    fireblast709

  24. Offline

    PotatoLol12321

  25. Offline

    Rocoty

    PotatoLol12321 Did you read my post?
     
  26. Offline

    PotatoLol12321

    Rocoty So move the Show(Player) constructor to the Menu(Plugin) constructor?
     
  27. Offline

    Rocoty

    PotatoLol12321 You have two constructors for the Menu class. show(Player) is not one of them, and it isn't even a constructor. You seem to be confused about some concepts. Maybe you should consider revising/learning basic Java before continuing on making Bukkit plugins? It would make it a whole lot easier.
     
  28. Offline

    CentrumGuy

    I think he's right :p
     
  29. Offline

    teej107

    He is right. To avoid possible NPEs, it's always good to have one constructor do all the work, and have the other constructors create the data needed to call that one constructor.
     
  30. PotatoLol12321 do you even know what a constructor is doing? If you call new Menu(...) the constructor with the matching parameter will be executed. That means if you have 1 constructor Menu(Plugin p) and a second constructor Menu(MenuInv instance) and you call new Menu(this) in the class MenuInv, the constructor with the MenuInv parameter will be executed, not the one with the Plugin parameter! But your constructor with the MenuInv parameter isn't doing anything besides setting the private variable "plugin". You should move the whole code from the Plugin-Parameter-Constructor to the MenuInv-Constructor and delete the Plugin-Constructer after doing that. Because then your code is executed if you call new Menu(this) in a MenuInv class.
    Did you understand this?
     
Thread Status:
Not open for further replies.

Share This Page