SFML Game Development - Use of assert in resource holder

[Nexus]

I can only repeat myself: I agree that there are more complex use cases, but I don't consider them relevant in the scope of the book's ResourceHolder. I don't see where we would benefit from a larger API.

That's what I meant with "An exists() method provokes a different design: Users don't have a clear owner and scope of the resource anymore." Instead of requiring the resource to be loaded before it's used, users are then allowed to query for the availability, which leads to a different usage pattern. They start to load resources in multiple places, differentiate cases and use delayed loading. This however works against the original ideas (for example centralized loading, simplest possible usage, clear ownership).

When talking about design, you really have to keep in mind that we're not presenting the ultimate solution, but trying to find a good tradeoff between simplicity, flexibility, and suitability to teach new concepts. Those of you who have the book, please read the section "A typical use case", it explains the reasoning which led to the ResourceHolder API as it is now. Keep also in mind that we emphasize multiple times that the reader should not see himself limited by the basis we provide; it is always possible to extend the given code

[Tank]

When talking about design, you really have to keep in mind that we're not presenting the ultimate solution, but trying to find a good tradeoff between simplicity, flexibility, and suitability to teach new concepts.

I know, I just find it confusing to assert() and don't provide anything to avoid the trap. Adding exists() indeed changes how the resource holder is used, probably, but I see two options here:

1) If it makes using the class more secure, then it's probably the way to go. Personally I think exists() would not destroy any simplicity, flexibility or suitability.
2) Use find() instead of get(): The simple change of wording can result in a change of the return type, e.g. from Resource& to Resource*, thus indicating the possibility of a nullptr. In my opinion this is fine, because the word "find" includes finding nothing.

I'm fine with how it's written in the book, this is purely about principles and general code design. On the other side, my opinion is: Even if beginners are reading the book, there's nothing wrong showing what options you have and what might be a "better" solution, even at the cost of a little bit more complexity.

I'm actually happy that you guys are using assert().

[Ixrec]

Just because my last post was so stupid the way I wrote it, I felt I should clarify that what I meant to say was "throw an exception when you try to use textures that have already gone out of scope".  Should've read that a few more times before posting.

And in retrospect you guys are right about making loadFromFile throw an exception instead; usually all I do after checking the bool is throw one myself.