Re: Error handling in plperl and pltcl

On 12/3/2004 12:23 PM, Thomas Hallgren wrote:

> Jan Wieck wrote:
>
>> There is no "try" in Tcl.
>>
>> The syntax is
>>
>> catch { block-of-commands } [variable-name]
>>
>> Catch returns a numeric result, which is 0 if there was no exception
>> thrown inside of the block-of-commands. The interpreter result, which
>> would be the exceptions error message in cleartext, is assigned to the
>> optional variable specified. Thus, your code usually looks like this:
>>
>> if {[catch {statements-that-might-fail} err]} {
>> on-error-action
>> } else {
>> on-success-action
>> }
>
> Ok, I wasn't trying to write tcl ;-) just pseudo code proving a point.
> This particular point is only valid until you expose the savepoint API's
> (as you now suggest) though, so no disagreement there.

"as you now suggest"? I don't remember suggesting that. I concluded from
your statements that _you_ are against changing Tcl's catch but instead
want the savepoint functionality exposed to plain Tcl. So _you_ are
against _my_ suggestion because these two are mutually exclusive.

> Maybe Tcl programmers use catch very differently from what I'm used to
> with try/catch in C++, C#, and Java. There, it's very common that you
> use a catch to make sure that resources that you've utilized are freed
> up, to do error logging, and to deal with errors that are recoverable.
>
> If a catch containing an spi-function automatically implies a
> subtransaction, then it might affect how people design their code since
> the subtransaction is much more expensive then a mere catch.
>
> Ideally, in a scenario where the caller of foo also calls other
> functions and want to treat the whole call chain as a atomic, he would
> start a subtransaction and do all of those calls within one catch where
> an error condition would yield a rollback. Within each function he still
> might want to catch code that eventually contains spi-calls but not for
> the purpose of rolling back. The error condition is perhaps not even
> caused by the spi-call but by something else that happened within the
> same block of code. If it's unrecoverable, then he re-throws the error
> of course.

You want the capabilities of C or Assembler (including all possible
failures that lead to corruptions) in a trusted procedural language. I
call that far from "ideal".

>
> The catch functionality is likely to be lean and mean. Implied
> subtransactions will make it slower and thus not as suitable for control
> flow as it normally would be. Where I come from, frequent use of
> try/catch is encouraged since it results in good program design. I'm
> concerned that what you are suggesting will make developers think twice
> before they use a catch since they know what's implied.

The point we where coming from was Tom's proposal to wrap each and every
single SPI call into its own subtransaction for semantic reasons. My
proposal was an improvement to that with respect to performance and IMHO
also better matching the semantics.

Your suggestion to expose a plain savepoint interface to the programmer
leads directly to the possiblity to commit a savepoint made by a
sub-function in the caller and vice versa - which if I understood Tom
correctly is what we need to avoid.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #