Messages

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.

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!

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.