Pour ma part, je n'utiliserais ni les exceptions, ni encore pire, les structures de contrôle sans accolades.
Les exceptions ne sont pas gratuites en termes de taille de code (sur une base de code significative basée sur Qt, j'avais trouvé une différence proche de 20% ), et leur traitement des exceptions peut nécessiter des allocations mémoire et aggraver les OOM.
Les structures de contrôle sans accolades sont connues pour avoir causé, par exemple, un bug de sécurité grave dans le kernel Linux il y a des années. A titre professionnel, j'avais trouvé un test faux de la forme
[code]if (condition)
statement;
return value;

statements[/code]
qui masquait un vrai bug dans le code testé.


De nos jours, j'utiliserais probablement quelque chose comme
[code]
bool success = false; // ou plutôt une enum, éventuellement typée en C++11 et dialectes ultérieurs, contenant des codes de retour
do {
m_Texture = SDL_CreateTexture(Game::get()->renderer(), px, SDL_TEXTUREACCESS_TARGET, width, height);
// Séparation de toutes les conditions du if, pour permettre un éventuel ajout individuel de message d'erreur ou traitement particulier, un jour.
if (nullptr == m_Texture) {
break;
}

// Ici, par habitude, j'omettrais probablement "0 !=", mais c'est mal)
if (0 != SDL_SetTextureBlendMode(m_Texture, SDL_BLENDMODE_BLEND)) {
break;
}

if (0 != SDL_SetRenderDrawColor(Game::get()->renderer(), 0, 0, 0, 0)) {
break;
}

if (0 != SDL_RenderClear(Game::get()->renderer())) {
break;
}

if (0 != SDL_SetRenderTarget(Game::get()->renderer(), m_Texture)) {
break;
}
success = true;
} while(0);

if (<success_value> != success) { // si success est un booléen, version abrégée
cleanup(); // cleanup doit être capable de gérer le fait que m_Texture == nullptr.
}

// Plus loin, une forme de "return success;", pour signaler l'erreur à l'appelant - c'est à l'appelant de traiter ou propager l'erreur.
[/code]

Et ce serait intéressant de voir ce que pense Ximoon de nos morceaux de code