Re: Error handling in plperl and pltcl

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.

> Your example shows where leaving the burdon on the programmer can
> improve performance. But change it to this:
>
> foo {} {
> spi-calls;
>
> if {[catch {spi-call} err]} {
> return "boo: $err"
> }
> return "hooray"
> }
>
> This function never throws any exception. And any normal Tcl
> programmer would expect that the spi-calls done before the catch will
> either abort the function on exception, or if they succeed, they get
> committed. What you mean with "normal" savepoint handling in fact
> means that we don't change catch at all but just expose the savepoint
> feature on the Tcl level.

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.

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.

I still believe that both catch (with try or no try) and savepoints are
simple and well known concepts that will benefit from being kept separate.

Regards,
Thomas Hallgren