Re: UU: DB: Exception differentiation

["Alexey Parshin" <alexeyp@gmail.com>]

Actually, I was talking about application. Basically, all the exceptions (PG internal and thrown by us) have the very similar impact on the page flow: user can't continue. The only difference is the suggestion on what the user should do in response. Some exceptions, like some connection or time out problems, can go away after awhile, so we can suggest user to pause and do it again in some time. Some exceptions suggest invalid data that user should fix before continue. And the rest is 'system can't do it because..', like permission problems or system fail that user can't fix but possibly can report. In ether case the message translation code is the same, and it doesn't depend on the exception class. I've done in the past, in the database, as a table of message formats. The table structure for this task was:

create table message_format (
   mf_id serial primary key,
   mf_message_code int references message_code(mc_id),
   mf_language int references language_list(ll_id),
   mf_format VARCHAR(80)
);

In this table, you always have a set of formats for the default language, and optionally a set of formats per language. If some message format isn't translated (doesn't exist for the language), then the default language message format is used. The format text may use the parameters passed as pipe-separated set of values.

In any case, the idea here is - to use message code (that can be varchar if you want) and message parameters, like (in the procedure):

-- format is:  'The user %, % does not have an account'

PERFORM throw_exception(
   123,  --exception code
   'John Doe|the principal'  -- exception parameters
);

Now, what is important here is: we don't need any exception classes but CException for this to work. I can imagine CUserException, at most. CConnectionException is a separate story so it doesn't count.

The only problem is system exceptions like key violation etc.. These should be translated into the message codes (above) by using regexp.

All this I already tried (not in PG but in Informix) and it all worked just fine with a single exception class. We can step further if the message code is accompanied with required user action (extra field in the table above), and message severity. For this we may add a single exception class, CUserException (see above) containing that info.

Let me know if you still insist on multiple exception classes.. I can work on it after vacation (Jan 5th..)

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

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

-- 
Alexey Parshin,
http://www.sptk.net