Re: [groovy-dev] advice needed

Alex Tkachman wrote:
> Paul!
> 
> I am 100% agree that we should not add return in to finally. What do
> you think about catch? After experiments I started to think that catch
> clause needs syntetic return

Do you have an example where you think it is useful/needed?

Paul.

> On Sun, Jun 22, 2008 at 4:33 AM, Paul King <paulk@...> wrote:
>> Alex Tkachman wrote:
>>> Hi!
>>>
>>> I've implemented default return from if/else
>>>
>>> def f () {
>>>   if (true)
>>>      1
>>> }
>>>
>>> assertEquals 1, f()
>>>
>>> It is not commited yet but works nicely including nested ifs, closures
>>> etc.
>>>
>>> Now I try to do the same for switch (which is relatively easy) and
>>> try/catch/finally (which is complicated), obviously that unfortunately
>>> there is no intuitively clear meaning of such return for loops.
>>>
>>> The main problem with try/catch/finally is how should it work. The
>>> question is what should be returned in case of last statement
>>> try {
>>>  ......
>>>  1
>>> }
>>> catch (Throwable t) {
>>>  "exception"
>>> }
>>> finally {
>>>  0
>>> }
>>>
>>> My idea is that it should return either 1 or null (if exception
>>> happen). Saying strongly - we add syntetic returns inside try block
>>> but not inside catch or finally blocks.
>>>
>>> Does it make sense?
>>> Could somebody suggest more reasonable behavior?
>> In Java and Groovy, if you had return 0 in the finally block, then
>> that would be returned even if an exception was thrown. It is often
>> considered a smell though to have a return in a finally block as
>> masking an exception in such a way can be very confusing and hard
>> to debug.
>>
>> So I would be inclined not to add a synthetic return in for finally.
>> It does mean we can't have simple explanations like 'Groovy always
>> returns the value of the last expression calculated in any statement'
>> but I think that is OK. In the finally example, you can always add
>> an explicit return. If you have a DSL with try ... catch ... finally
>> expressions then another keyword (return) is probably not going to
>> look that strange if you really want that behavior which I doubt.
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>     http://xircles.codehaus.org/manage_email
> 
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email