Hello!
My situation is pretty standard: I get conditions of one type from
database layer (CLSQL) and I need to raise conditions of another type
at CORBA layer. I make it by catching SQL-ERRORs and throwing my CORBA
errrors. And this I do in every method, just like in old bad C++ times
(though through a macro).
It seems to me there should be a better solution, like automagic
condition convertation, or global handler, or something like...
Thanks for your opinions,
Dmitri
Perhaps I am missing something, but why does this need to be bound in
every method?. Since error handlers are dynamically bound why can't
this be done in some encompassing calling code?
>>>>> "yavannadil" == yavannadil <··········@yahoo.com> writes:
yavannadil> Hello! My situation is pretty standard: I get
yavannadil> conditions of one type from database layer (CLSQL) and
yavannadil> I need to raise conditions of another type at CORBA
yavannadil> layer. I make it by catching SQL-ERRORs and throwing
yavannadil> my CORBA errrors. And this I do in every method, just
yavannadil> like in old bad C++ times (though through a macro).
yavannadil> It seems to me there should be a better solution, like
yavannadil> automagic condition convertation, or global handler,
yavannadil> or something like...
yavannadil> Thanks for your opinions, Dmitri
--
Dr. John A.R. Williams PGP key: 6606795A185C384C
Photonics Research Group, Postgraduate Programme Director
Electronic Engineering, Aston University, Birmingham B4 7ET
Tel: 0121 204 3543 www:http://www.ee.aston.ac.uk/contacts/willijar.html
··········@yahoo.com wrote:
> Hello!
>
> My situation is pretty standard: I get conditions of one type from
> database layer (CLSQL) and I need to raise conditions of another type
> at CORBA layer. I make it by catching SQL-ERRORs and throwing my CORBA
> errrors. And this I do in every method, just like in old bad C++ times
> (though through a macro).
This smacks like a C++ solution. In Lisp, you can have a handler
somewhere higher up in the dynamic environment (call chain). Remember,
when Lisp searches for a handler for a condition within the dynamic
context, no unwinding takes place! In principle, one handler somewhere
at the top (or at the top of every thread) can take the SQL-ERROR
condition, and signal a different one based on it.
Maybe you are using HANDLER-CASE instead of HANDLER-BIND?
> It seems to me there should be a better solution, like automagic
> condition convertation, or global handler, or something like...
There is no "global handler" but a close approximation is a handler
whose binding is set up around the call to whatever serves as your main
function.
··········@yahoo.com writes:
> My situation is pretty standard: I get conditions of one type from
> database layer (CLSQL) and I need to raise conditions of another type
> at CORBA layer. I make it by catching SQL-ERRORs and throwing my CORBA
> errrors. And this I do in every method, just like in old bad C++ times
> (though through a macro).
> It seems to me there should be a better solution, like automagic
> condition convertation, or global handler, or something like...
I think you may be closer to being "ok" than you believe. Presumably
the situation is something like the following:
client-x
|
Corba Call
|
V
Lisp Application
| |
SQL/ |
ODBC/ Other Similar Kinds of Calls
Proprietary |
Call V
| Various other Services
V
RDB
Probably this also is set up so that each Corba call is handled by a
Corba method in its own thread, or maybe there is one such thread
which multiplexs Corba Client methods, though that makes things
unnecessarily more complicated and messy. Anyway, one technique that
I've used to very good effect is to define a macro which is used to
define your Corba methods. I know your ORB provider already provides
one of those, but it is too generic for what you want here.
In your macro, you use the vendors method but wrap the body of the
method with your own handler code. In particular, this code will
check to see if it should signal the debugger instead of raising an
interface exception back over in the client. This way, you will have
the chance to debug a method call in progress and restart it to see if
you have it properly fixed (which will then correctly complete and the
client will be happy).
If you don't have ORB method debugging on, then your code will check
to see if the condition is a Corba exception. If so, just pass it on
through to the client. If not, you need to turn the condition into
one of the exception types defined in your interface. Actually, most
likely you don't want general conditions, but just errors to be so
handled.
Now, no non Corba method or ordinary function need know or care
whether it is in the dynamic extent of a Corba call. They can just
use the standard CL condition machinery and a programmer of them can
proceed as if there were no distributed invocations at all.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Thanks to everybody!
I'll try to wrap HANDLER-BIND (yes, I thought it involved unwinding)
around (OP:RUN ORB) for starters, and if it won't work/I'll need more
control, I'll return to per-method macro.
From: Coby Beck
Subject: Re: "convert" one condition to another
Date:
Message-ID: <kfgqf.8$OU5.2@clgrps13>
<··········@yahoo.com> wrote in message
····························@g47g2000cwa.googlegroups.com...
> Thanks to everybody!
>
> I'll try to wrap HANDLER-BIND (yes, I thought it involved unwinding)
> around (OP:RUN ORB) for starters, and if it won't work/I'll need more
> control, I'll return to per-method macro.
Don't forget it is not an either/or choice, use both approaches. Put your
initial and very general handler around top level code and then as the
situation requires put more specific handlers inside methods that can more
clearly express specific actions.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")