[
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.
Ilya.
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.
Ilya.
--
Alexey Parshin,
http://www.sptk.net