[EMAIL PROTECTED] (Tom Lane) wrote:
> Does anyone have a problem with this macro syntax? The try/catch
> names are stolen from Java, so I'm figuring they won't terribly
> surprise any modern programmer, but I'm open to different names if
> anyone has a better idea.
Mitch Bradley, once of Sun, onc
On 07/31/04:30/6, Tom Lane wrote:
> Is there any actual functional usefulness to that, or is it just to
> avoid having to reorder existing code to fit into the try/catch paradigm?
Both, I imagine. In the case of the former, it *may be* useful for someone to
create their own paradigm, which seems li
James William Pye <[EMAIL PROTECTED]> writes:
> On 07/28/04:30/3, Tom Lane wrote:
>> Does anyone have a problem with this macro syntax? The try/catch names
>> are stolen from Java, so I'm figuring they won't terribly surprise any
>> modern programmer, but I'm open to different names if anyone has
On 07/28/04:30/3, Tom Lane wrote:
> In service of the refactoring of error handling that I was talking about
> a few days ago, I'm finding that there are several places that really
> ought to catch longjmps and clean up after themselves, instead of
> expecting that whatever mess they've made will b
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
This is especially a problem when the cleanup needs to be done inside
the embedded interpreter. I found that with R, I had to throw an error
in the R interpreter in order to allow the interpreter to clean up its
own state. That left me with
On Thu, Jul 29, 2004 at 09:58:54AM -0400, Tom Lane wrote:
> Right. The last bit (FINALLY executes whether or not a CATCH block
> re-throws) seemed too messy to handle in my little macros, so I'm
> planning on leaving it out. But I'm open to the idea if anyone has
> a clever implementation thoug
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> ...Or I could try. Yes, the "finally" block is executed after executing
> the "catch" block if an exception was caught, or when leaving the "try"
> block if there wasn't. That includes both normal completion and uncaught
> exceptions.
Right. T
Joe Conway <[EMAIL PROTECTED]> writes:
> This is especially a problem when the cleanup needs to be done inside
> the embedded interpreter. I found that with R, I had to throw an error
> in the R interpreter in order to allow the interpreter to clean up its
> own state. That left me with code lik
On Thu, Jul 29, 2004 at 12:10:12AM -0400, Alvaro Herrera Munoz wrote:
> (The "finally" block, AFAIU, is executed whether an exception was raised
> or not, so it serves as cleanup for try and catch blocks. Somebody more
> knowledgeable in this OO matters may enlighten us better?)
...Or I could t
Tom Lane wrote:
In service of the refactoring of error handling that I was talking about
a few days ago, I'm finding that there are several places that really
ought to catch longjmps and clean up after themselves, instead of
expecting that whatever mess they've made will be cleaned up for them
when
> Does anyone have a problem with this macro syntax? The try/catch names
> are stolen from Java, so I'm figuring they won't terribly surprise any
> modern programmer, but I'm open to different names if anyone has a
> better idea.
I have done such a macro hiding of setjmp/longjmp for a math libra
On Wed, Jul 28, 2004 at 08:19:17PM -0400, Tom Lane wrote:
Very cool and interesting idea.
> Does anyone have a problem with this macro syntax? The try/catch names
> are stolen from Java, so I'm figuring they won't terribly surprise any
> modern programmer, but I'm open to different names if anyo
On Wed, 28 Jul 2004, Tom Lane wrote:
> In service of the refactoring of error handling that I was talking about
> a few days ago, I'm finding that there are several places that really
> ought to catch longjmps and clean up after themselves, instead of
> expecting that whatever mess they've made wi
13 matches
Mail list logo
