Error Handling
« on: 14 September 2014, 00:13:28 »
So I set up some tabs based on the tab example code and its pretty much fine except one issue. When Tab causes the program to crash it doesn't say why, even when I was running debug mode. It turns out in the tab show/hide function I hadn't changed the name from Unused2 to Populations. But it took me some time and an epiphany to realize this, and this was after I knew that the problem existed although I didn't know it was messing me up right then. The function should ideally return some sort of couldn't find a panel with that name error or something, instead of just crashing right off.

*

texus

  • *****
  • 1161
    • View Profile
    • Texus's Blog
Re: Error Handling
« Reply #1 on: 14 September 2014, 00:29:23 »
Your description is a bit vague. I don't see anything about the Tab class that should be crashing, so I assume you are talking about the get function from Gui in the tab example code?

The get function returns a pointer to the widget, or nullptr when the widget isn't found. If you try to call a function on a nullptr it will crash of course. The only thing I can do about that is throw an exception instead of returning a nullptr, but that might not always be wanted.

You should always be able to find a call stack somewhere when debugging. That usually gives enough information about where it happened. The last line might perhaps be in a tgui function with this=0x0 which can tell you that you called that function on a nullptr.

But if you weren't talking about the get function then you will have to be a bit more specific than "The function".

Re: Error Handling
« Reply #2 on: 14 September 2014, 00:49:23 »
Your description is a bit vague. I don't see anything about the Tab class that should be crashing, so I assume you are talking about the get function from Gui in the tab example code?

The get function returns a pointer to the widget, or nullptr when the widget isn't found. If you try to call a function on a nullptr it will crash of course. The only thing I can do about that is throw an exception instead of returning a nullptr, but that might not always be wanted.

You should always be able to find a call stack somewhere when debugging. That usually gives enough information about where it happened. The last line might perhaps be in a tgui function with this=0x0 which can tell you that you called that function on a nullptr.

But if you weren't talking about the get function then you will have to be a bit more specific than "The function".

Yes the get function sorry. And no, this produces no callstack. The program exits with code 3. According to google this means an uncaught exception or "the system cannot find the path specified." Not sure how this would apply to your get function though.

*

texus

  • *****
  • 1161
    • View Profile
    • Texus's Blog
Re: Error Handling
« Reply #3 on: 14 September 2014, 01:00:53 »
Quote
this produces no callstack
If you crash in debug mode then the debugger should break somewhere and you should have a call stack. It might just not be a visible window by default. You should look up where the callstack is for your ide.

Error codes don't really say much, but if you print out the return value of the get call then I'm sure its going to be a nullptr. The code inside the get function itself can't really crash unless by a serious error on my side, but then everyone would have problems with it.

Re: Error Handling
« Reply #4 on: 14 September 2014, 03:21:58 »
I get the call stack the rest of the time, just not on this particular crash. Basically its just what happens if the panel name given to the get function doesn't match the name a valid panel.

Re: Error Handling
« Reply #5 on: 14 September 2014, 04:43:51 »
I just got an error with nullptr for a different thing. Assertion failed: m_WidgetPtr != nullptr. Is that what you thought I should get before?

*

texus

  • *****
  • 1161
    • View Profile
    • Texus's Blog
Re: Error Handling
« Reply #6 on: 14 September 2014, 11:11:22 »
Quote
Is that what you thought I should get before?
Yeah. I forgot that I was still using my own smart pointer in v0.6. That assertion is indeed what you get with v0.6.

I can't debug it from here, that's why I need to have more information somehow.
Just try using this code:
Code: [Select]
std::cout << gui.get("WrongName").get() << std::endl; // the last get() may or may not be needed to print the pointer
If that prints something that looks like a null pointer, then I can't do anything and it works as expected.
If that crashes, then could you upload your entire project including sfml and tgui libraries somewhere (e.g. dropbox) and send me the link? Then I may be able to test things myself here.

Re: Error Handling
« Reply #7 on: 14 September 2014, 14:30:21 »
Quote
Is that what you thought I should get before?
Yeah. I forgot that I was still using my own smart pointer in v0.6. That assertion is indeed what you get with v0.6.

I can't debug it from here, that's why I need to have more information somehow.
Just try using this code:
Code: [Select]
std::cout << gui.get("WrongName").get() << std::endl; // the last get() may or may not be needed to print the pointer
If that prints something that looks like a null pointer, then I can't do anything and it works as expected.
If that crashes, then could you upload your entire project including sfml and tgui libraries somewhere (e.g. dropbox) and send me the link? Then I may be able to test things myself here.

That was a different error that caused the console message, I tried to hide something before it was there and it wasn't the get function this time. That's working as expected I'd imagine.

*

texus

  • *****
  • 1161
    • View Profile
    • Texus's Blog
Re: Error Handling
« Reply #8 on: 14 September 2014, 14:33:49 »
My post was still about the original issue, you should try that code on the place where the get function was crashing.