Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Voor traditionele C-programmeurs worden fouten meestal geretourneerd via retourwaarden of een speciale [out]-parameter die de foutcode retourneert. Dit leidt tot interfaces die op de volgende manier zijn geïmplementeerd:
long sample(...)
{
...
p = new Cbar(...);
if (p == NULL)
{
// cleanup
...
return ERROR_OUTOFMEMORY;
}
}
Het probleem met deze benadering is dat RPC-retourwaarden gewoon lange gehele getallen zijn. Ze hebben geen speciale betekenis als fouten (houd er rekening mee dat error_status_t geen speciale semantiek aan de serverzijde heeft), wat belangrijke gevolgen heeft.
Ten eerste wordt RPC niet gewaarschuwd dat de bewerking is mislukt; het probeert alle argumenten [in, uit] en [uit] te verwijderen. De foutsemantiek van contextgrepen verschilt ook. Het pakket dat naar de client wordt geretourneerd, is in wezen een succespakket, waarbij de foutcode diep in het pakket is begraven. Dit betekent ook dat RPC geen uitgebreide foutinformatie gebruikt, dus clientsoftware kan vaak niet zien waar de aanroep is mislukt.
Het aangeven van fouten in RPC-serverroutines door SEH-uitzonderingen (Structured Exception Handling) (niet C++) te genereren, is een veel betere aanpak. Wanneer er een SEH-uitzondering wordt gegenereerd, wordt het besturingselement rechtstreeks naar de RPC-uitvoeringstijd geleid. Een fout treedt soms diep op in een routine die niet goed kan worden opgeschoond en moet een fout aan de aanroeper aangeven. De routine moet een fout retourneren aan de aanroeper, die op zijn beurt een fout kan retourneren aan de beller, enzovoort. De laatste serverroutine op de stack moet echter een uitzondering genereren voordat deze terugkeert naar RPC om aan te geven dat er een fout is opgetreden.
Verwante onderwerpen