1. Screw with C code callbacks, ie. when getting thrown in Lua wrapper when Lua wasn't compiled as c++(not the brightest idea, but doable).
2. Screw with literally every language, so now C wrapper for porting has to catch exceptions and return error code and then let wrapper language do something sane(throw? error code? `rm -rf /` ?) with that code.
3.The fuss of converting error code to exception is way way lesser than fuss of converting exception into error code:
Code to throw:
if (tex.loadFromFile("pic.jpg")) throw loadFromFileFailed();
One liner, literally.
Throw to code:
try
{
tex.loadFromFile("pic.jpg");
}
catch(loadFromFileFailed& e)
{//by this point I am already kind of discouraged and want to go play with some other library that doesn't force exceptions
return errcode::loadFromFileFailed;
}
No comment, looks stupid, definitely can't be faster, might be slower, pointless as hell.
4. Consider use case of an imaginary unix-y style tool for checking your ready-to-deploy zip/pack/bundle/game.laurent file/folder to ensure all textures load ok in SFML, takes a list of texture paths on stdin and outputs them with info about SFML compatibility on stdout:
int main()
{
std::string name;
sf::Texture tex;
std::cout<<std::boolalpha;//pretty bool printing
while(std::getline(std::cin,name))
{
std::cout<<name<<"loadable via SFML:"<<tex.loadFromFile(name)<<std::endl;
}
}
With everything-is-throwing-cause-modern-cpp-is-one-size-fits-all:
int main()
{
std::string name;
sf::Texture tex;
std::cout<<std::boolalpha;//pretty bool printing
while(std::getline(std::cin,name))
{
try
{
std::cout<<name<<"loadable via SFML:";
tex.loadFromFile(name);//returns void but can throw loadFromFileFailed
std::cout<<true<<std::endl;
}
catch(loadFromFileFailed& e)
{
std::cout<<false<<std::endl;
}
}
}
Consider based on 3. and 4. how much harder it can be to come up with use case where error code you'd prefer to be exception is more cumbersome than exception that you don't want(stupid programmer who ignores returned codes and then has issues about his textures being white and sounds missing because loads actually failed and returned false he didn't check for doesn't count, he could as well ignore result of malloc and have a memory leak, functions return for a reason, he will pray exceptions don't happen or make giants try{}catch(...){} blocks and then have the same problem).
5. Screw with C resources, almost every C library is a c++ one:
some_c_resource * resource=open_something_c();
sf::Texture tex;
//lets say we use that resource to look up name of texture we want
tex.loadFromFile(look_up_value_of_attr_as_str(resource,"texname"));//BTW all your C resources are belong to Laurent if this throws and you don't catch it here, close them and then rethrow, hehe, happy boilerplate writing <3
5.1. Yes, you can write wrappers or use template parameter deleter in smart ptr to close C resources OR write non throwing api that returns codes around this one. You probably should wrap your C stuff when you're forced by real user case of your code or want to make your work easier, not by arbitrary design choice of a library made to be more 'modern'. You're fighting the library at this point, go pick up SDL or GLFW or something else.
6. They are explicitly designed to take control away from my code and so they introduce boilerplate and make me fight the library if I don't want something like a texture manager to throw, and even if I did, they'd be my well organised coherent exceptions, not thor and sfml going to town on my scopes with over generalized exceptions thrown from too low to have enough context, 'textureloadingfromfile' failed, yep, I'll totally catch that 10 places in call stack from now on, and totally distinguish that certain texture loading from another one in another module at another time... It'll end up being ignored or used one place up just like an error code would.
A texture manager should just get given a list of data handles that are from disc, ram, wherever via inputstream interface, load texture from each and report how many it loaded, it's not supposed to be verifying anything. If needed it's state(amount of textures actually loaded) can be checked by higher system and then it can throw if needed. Maybe this higher system that uses this class isn't so throw trigger happy, maybe it's that unixy tool that will just check if all textures load ok. Don't assume I want to bail scopes on all failures(because with everything-uses-exceptions you do assume just that, that or that I want to write additional empty catch in case I don't want to bail..).
I really dislike exceptions overuse and find them annoying unless they're done like Lua, Boost and/or used sparsely when it makes sense.
