On Mon, Feb 20, 2012 at 10:32:48PM -0300, Juan Manuel Cabo wrote: > Well... then why did this mistakes exist?: > > In dot NET: > > ComException - Exception encapsulating COM HRESULT information > SEHException Exception encapsulating Win32 structured exception > handling information.z > > http://msdn.microsoft.com/en-us/library/z4c5tckx%28v=VS.71%29.aspx
I couldn't tell you, I didn't design this. > And why do you think that a thing like standardizing DatabaseException > never survives users, and that each database manager library defines > its own top *DatabaseException base class? Perhaps because when users chose to use the Oracle engine, they want to deal with Oracle-specific features including Oracle error codes directly? So a generalized SQL exception designed under some idealized database framework would only get in their way? > This is a universal problem with transversal traits of exceptions. [...] True, so now we're trying to fix this by having *both* an exception class hierarchy *and* what amounts to a generic varbind that stores transversal information? If Oracle error codes are what the user wants, then giving them a pretty exception class hierarchy is sorta pointless. They just want an OracleException containing the Oracle error code. They couldn't care less if there was a SQLParseErrorException or a SQLCannotAcquireLockException. It would be a waste of effort to build a pretty hierarchy for them if they're just going to ignore it and use Oracle error codes anyway. If we're really trying to solve transversal problems, then I have the feeling that this will require something more than just slapping a Variant[string] onto the Exception class. We need to re-examine the entire model of what exceptions are and what's the best way to deal with them. In the case of Phobos, we're not really dealing with the same kind of situation (not yet, anyway). Phobos modules, in general, aren't merely thin wrappers around a self-contained external module the same way an Oracle API is just a thin wrapper over an independent Oracle driver built by an independent party. So we get to define our own game, in a sense. There's no Oracle error code to map, and we can enforce the proper use of an exception class hierarchy. If someone wants direct access to errno, say, they could just call the C API directly -- D was designed not to require wrappers in that case. But still, I concede that class hierarchies don't solve everything. Sometimes we do need something more. But slapping on a Variant[string] onto the existing system seems like merely a workaround, not a real solution. T -- Study gravitation, it's a field with a lot of potential.
