On Mon, 13 Feb 2006 03:07:26 -0500, John Denker said: > That might lead to an argument in favor of exceptions instead of error > codes, along the following lines: > -- Naive code doesn't catch the exception. However (unlike returned > error codes) this does not cause the exception to be lost. > -- The exception percolates up the call-tree until it is caught by > some non-naive code (if any). > -- If all the code is naive, then the uncaught exception terminates > the process ... to the delight of the "exit on error" faction. > However (!!!) unlike a plain old exit, throwing an exception leaves > the door open for non-naive code to implement a nuanced response to > the exceptional condition.
Actually the plain C similar thing is done for an internal error: SIGABRT is raised and the top level code (or in theory any layer in between) may catch it and try to continue. Okay, this won't work in practise because signal handling between independent developed code (libraries) is guaranteed not to work correctly. And yes, we need to discuss whether whether a failed open should abort or exit. As of now it does an exit and not an abort() but I won't insist on this. > Again, enough false dichotomies already! Just because error codes are > open to abuse doesn't mean exiting is the correct thing to do. For Libgcrypt's usage patterns I am still convinced that it is the right decision. Salam-Shalom, Werner --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]