Quote from: GetterSetter on 09 April 2024, 19:44:32Quote from: cg923 on 09 April 2024, 19:31:13doesn't your original problem disappearActually, 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.
Quote from: cg923 on 09 April 2024, 19:31:13doesn't your original problem disappearActually, 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.
Quote from: texus on 09 April 2024, 19:25:22make the first parameter a templateOh, that's even better. Thank you for your advice!
Quote from: GetterSetter on 09 April 2024, 16:17:37Quote from: cg923 on 08 April 2024, 18:50:18For 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.Quote from: cg923 on 08 April 2024, 18:50:18might be annoyingI 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).
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.QuoteI 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.
Quote from: cg923 on 08 April 2024, 18:50:18For 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.
Quote from: cg923 on 08 April 2024, 18:50:18might be annoyingI 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).