well within what the language already allows. Panic and conditional,
interdependent recover schemes can be made quite convoluted. Still for 90%
of the practical use cases, if not 99%, there is just one panic and one
conditionally considered recover. I think the same practicalities would
apply here as well -- that x != nil would likely account for 90% of the
uses. Still, I would agree that limiting the conditional to some simple
subset of possible expressions and baring side-effects would likely be a
good thing.
In terms of ordering, I would choose a simple definition that the first
trap and first defer wins, where first trap is defined by the left to right
ordering of the returned variables and first defer by the top-down order of
the conditional defer statements that reference that variable as part of
their condition, with all of the returned values being available in the
evaluation of the conditional.
Whether to allow a conditional defer to 'recover' is another interesting
question. You might get that capability for free, since an implementation
of the conditional would only (hopefully) affect how you get into a defer.
Once in, would there be any difference from having arrived via a panic?
On Tuesday, September 24, 2013 11:34:21 PM UTC-7, Jesse McNelis wrote:
On Wed, Sep 25, 2013 at 4:12 PM, <[email protected] <javascript:>>wrote:
You need to keep the traps in mind as you read each line of the function
since it could affect any line.
If you scale this up to 3 or four traps it becomes hard to keep the
effects of each of them in mind and they start in interact in complicated
ways.
What happens in this example and do you really want to keep that rule in
your head for every line of code in the function?
defer err != nil func() {
s.removeChild(parentRef, child)
} ()
defer parentRef != nil func() {
//something else
} ()
parentRef, err = s.findClientRef(cmd.WidgetId)
--
=====================
http://jessta.id.au
--On Wed, Sep 25, 2013 at 4:12 PM, <[email protected] <javascript:>>wrote:
The flow control could be made clear: the defer defines a simple
expression that, when evaluated to true, acts to end the enclosing
function, allowing standard defer processing at close of function scope to
proceed. The condition defined by the expression would only be evaluated
when a function returns and sets the variable named in the expression. In
effect, a trap on the change of a variable value.
But that flow is only clear in the context of reading the whole function.expression that, when evaluated to true, acts to end the enclosing
function, allowing standard defer processing at close of function scope to
proceed. The condition defined by the expression would only be evaluated
when a function returns and sets the variable named in the expression. In
effect, a trap on the change of a variable value.
You need to keep the traps in mind as you read each line of the function
since it could affect any line.
If you scale this up to 3 or four traps it becomes hard to keep the
effects of each of them in mind and they start in interact in complicated
ways.
What happens in this example and do you really want to keep that rule in
your head for every line of code in the function?
defer err != nil func() {
s.removeChild(parentRef, child)
} ()
defer parentRef != nil func() {
//something else
} ()
parentRef, err = s.findClientRef(cmd.WidgetId)
--
=====================
http://jessta.id.au
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
