Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UU: DB: Exception differentiation

I definitely agree that it doesn't pay in a library of generic code.
It does, however, have significant advantages when done right in
app-specific ways. At this point I need to differentiate between
access violation, connection problem, and "others".

I guess once we have full list of exceptions, we can see how to
group them in the best way.

Re: machine->text - the way things are now, it's really hard
to internationalize. Once we have code->string mapping, which
will be done in C++, i18n will become far easier.


Alexey Parshin wrote:
I can scan UU procs for possible exception situations and define a list of exception classes, if you want. Then, I can add CUUDatabase class, and derive CConnection from CUUDatabase instead of CPostgreSQLDatabase.

BTW, the reason why I originally didn't add multiple exception classes into SPTK was pretty simple. I couldn't find significant code branching advantages, and translation from the original exception text to humanly readable was simpler with a single exception class. At some point I even had six or seven such classes - it doesn't pay.

2008/12/27 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com <mailto:ilya@total-knowledge.com>>

    Ilya A. Volynets-Evenbakh wrote:

        That sounds reasonable.

    BTW, I modified CRecordSet to special-case access violation
    exception in
    this way. Once you take care of CUUDatabase, those changes will
    need to
    be reverted.


Alexey Parshin,

Authoright © Total Knowledge: 2001-2008