Recent posts

#1

Feature requests / Re: Providing more information...

Last post by cg923 - 09 April 2024, 20:09:24

doesn't your original problem disappear

Actually, it doesn't. If get() throws the exception that isn't caught, the program will terminate and in the terminal I will be able to see what happened (what was the reason to terminate) whereas a nullptr dereference will cause a segfault without any explanation.

Ahh. Gotcha. Now I'm on the same page. I suppose my only reservation toward throwing an error there (I know Texus has already decided) is that I can imagine a case where returning nullptr is useful, and having an error get thrown there means one would need to catch that error and deal with it... which would be a simple rewrite of existing code but could be a breaking change. Wouldn't be the end of the world.

#2

Feature requests / Re: Providing more information...

Last post by GetterSetter - 09 April 2024, 19:44:32

doesn't your original problem disappear

Actually, it doesn't. If get() throws the exception that isn't caught, the program will terminate and in the terminal I will be able to see what happened (what was the reason to terminate) whereas a nullptr dereference will cause a segfault without any explanation.

#3

Feature requests / Re: Providing more information...

Last post by GetterSetter - 09 April 2024, 19:34:55

make the first parameter a template

Oh, that's even better. Thank you for your advice!

#4

Feature requests / Re: Providing more information...

Last post by cg923 - 09 April 2024, 19:31:13

For example, I might want to add a widget if get() returns nullptr, or something like that.

I can also do this in case of an exception being thrown, can't I? Anyway we have already discussed that using exceptions might break backwards compatibility, so the only thing I would be glad to see is some information in the terminal.

might be annoying

I admit that it might be, but isn't it annoying to spend time using a debugger only to figure out that there was a mistake in the naming? As Texus has suggested, we can use a global flag to disable these messages (or we may not print them in the release version of the library, but do it in the debug one).

You definitely can handle the errors that the library would throw, of course. But then, that would require that you'd be validating the results of the get() function already anyway, in which case, doesn't your original problem disappear? Validating that way is just a different way of doing that validation that would have prevented your segfault in the first place.

Looking at your previous post, the wrapper function seems like a good solution!

#5

Feature requests / Re: Providing more information...

Last post by texus - 09 April 2024, 19:25:22

Yes, that would be the solution.
You would indeed need a second function with tgui::Container::Ptr, unless you make the first parameter a template as well (but then you will need to pass "&gui" as argument when calling the function).

#6

Feature requests / Re: Providing more information...

Last post by GetterSetter - 09 April 2024, 19:14:29

Thank you for your reply, texus. I assume that in my case the best way to help myself is to write some wrapper functions, e.g.

Code Select Expand

        template <class WidgetType>
        typename WidgetType::Ptr get(tgui::Gui &gui,const String& widgetName) const
        {
            auto ptr=gui.get<WidgetType>(widgetName);
            if(ptr==nullptr) throw std::runtime_error("reason+widgetName");
            return ptr;
        }
+ the same function which is overloaded for tgui::Container* instead of tgui::Gui.

#7

Feature requests / Re: Providing more information...

Last post by texus - 09 April 2024, 18:42:13

I've given it some more thought and asked for some extra opinions about this issue on discord yesterday, and my decision is that I'm not going to change the API for this. I don't really want to add another function and extra code just to provide slightly better debug information in the case where the "get" function is used without proper error checking (i.e. testing if returned value is nullptr or not).

I can also do this in case of an exception being thrown, can't I?

Yes, you could catch the exception to find out that that the widget didn't exist. So no functionality would be lost. The code wouldn't look as clean as a simple if check though.

#8

Feature requests / Re: Providing more information...

Last post by GetterSetter - 09 April 2024, 16:17:37

For example, I might want to add a widget if get() returns nullptr, or something like that.

I can also do this in case of an exception being thrown, can't I? Anyway we have already discussed that using exceptions might break backwards compatibility, so the only thing I would be glad to see is some information in the terminal.

might be annoying

I admit that it might be, but isn't it annoying to spend time using a debugger only to figure out that there was a mistake in the naming? As Texus has suggested, we can use a global flag to disable these messages (or we may not print them in the release version of the library, but do it in the debug one).

#9

Feature requests / Re: Providing more information...

Last post by cg923 - 08 April 2024, 18:50:18

As much as I understand the desire for explicit information about why the function "failed," throwing an error here prevents us from handling the situation as we like if get() does return nullptr.

For example, I might want to add a widget if get() returns nullptr, or something like that. So, I definitely don't think that TGUI should throw an error, but perhaps just printing one to the console, although even that might be annoying if I'm expecting the behavior.

#10

Feature requests / Re: Providing more information...

Last post by GetterSetter - 08 April 2024, 10:53:16

I agree that it is not actually an error, but get() is almost always used to retrieve a known widget, so I have already mentioned that it's illogical to do a nullptr check and, consequently, we may not notice this error. However, if there is an intention to call get() using a name given by the user, for example through user input, then I will perform that check regardless. Moreover, in the context of get(), Gui behaves like a container (similar to std::map), and some behavior is expected when accessing out-of-range values. Additionally, using a debugger to locate such errors makes development harder. Therefore, my opinion is that get() should, at least print something to the terminal. I appreciate your suggestion about using a global flag, and I believe it is a good solution. Throwing an exception seems like a more modern approach to using C++. But anyway the final decision rests with you. Would you be so kind as to notify me later about your findings here?