Alex Tkachman | 21 Jun 23:34

[groovy-dev] advice needed

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
}

(Continue reading)

Luke Daley | 22 Jun 01:01

Re: [groovy-dev] advice needed


On 22/06/2008, at 7:36 AM, Alex Tkachman wrote:

> 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?

Seems logical to me.

LD>

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

    http://xircles.codehaus.org/manage_email

Martin C. Martin | 22 Jun 02:12

Re: [groovy-dev] advice needed

See:

http://jira.codehaus.org/browse/GROOVY-715

Best,
Martin

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
(Continue reading)

Russel Winder | 23 Jun 07:32

Re: [groovy-dev] advice needed

On Sat, 2008-06-21 at 20:12 -0400, Martin C. Martin wrote:
> See:
> 
> http://jira.codehaus.org/browse/GROOVY-715
> 
> Best,
> Martin

I never did like that decision but was prepared to live with it since
there was the ?: operator.

--

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
Paul King | 22 Jun 02:33

Re: [groovy-dev] advice needed

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
> }
(Continue reading)

Alex Tkachman | 22 Jun 06:56

Re: [groovy-dev] advice needed

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

Alex

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
(Continue reading)

Paul King | 22 Jun 09:07

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.
(Continue reading)

Alex Tkachman | 22 Jun 09:28

Re: [groovy-dev] advice needed

sure

def getSomething (def obj) {
  try {
     obj.something
  }
  catch(NullPointerException) {
     globalSometing
  }
}

On Sun, Jun 22, 2008 at 11:07 AM, Paul King <paulk@...> wrote:
> 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!
>>>>
(Continue reading)

Paul King | 22 Jun 21:43

Re: [groovy-dev] advice needed

Alex Tkachman wrote:
> sure
> 
> def getSomething (def obj) {
>   try {
>      obj.something
>   }
>   catch(NullPointerException) {
>      globalSometing
>   }
> }

Yes, I think this should have a synthetic return.
If we can tell which cases are throws, we certainly
don't need to do anything in those cases.

Paul.

> On Sun, Jun 22, 2008 at 11:07 AM, Paul King <paulk@...> wrote:
>> 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:
(Continue reading)

Andres Almiray | 22 Jun 22:44

Re: [groovy-dev] advice needed


+1 on synthetic return in try
-1 on synthetic return on catch/finally

reason being you write catch/finally because you expect something may go
wrong, so I believe you should be very careful in those code sections and
leave your expectations unambiguous, i.e., set your returns explicitly.

Paul King wrote:
> 
> Alex Tkachman wrote:
>> sure
>> 
>> def getSomething (def obj) {
>>   try {
>>      obj.something
>>   }
>>   catch(NullPointerException) {
>>      globalSometing
>>   }
>> }
> 
> Yes, I think this should have a synthetic return.
> If we can tell which cases are throws, we certainly
> don't need to do anything in those cases.
> 
> Paul.
> 
>> On Sun, Jun 22, 2008 at 11:07 AM, Paul King <paulk@...> wrote:
>>> Alex Tkachman wrote:
(Continue reading)

Robert Fischer | 22 Jun 23:00

Re: [groovy-dev] advice needed

If we *don't* have synthetic returns in catch statements, what would the result of this method call?

def foo() {
  try {
    throw new RuntimeException()
  } catch(Exception e) {
  }
}

I'm inclined to being opposed to both try and catch/finally blocks because of flow-of-control
problems like this: it's tricky to follow.  If you want a synthetic return, capture the return value
and put it after the try/catch/finally.  Or use an explicit return.

~~ Robert.

Andres Almiray wrote:
> +1 on synthetic return in try
> -1 on synthetic return on catch/finally
> 
> reason being you write catch/finally because you expect something may go
> wrong, so I believe you should be very careful in those code sections and
> leave your expectations unambiguous, i.e., set your returns explicitly.
> 
> 
> Paul King wrote:
>> Alex Tkachman wrote:
>>> sure
>>>
>>> def getSomething (def obj) {
>>>   try {
(Continue reading)

Alex Tkachman | 23 Jun 00:15

Re: [groovy-dev] advice needed

First of all you have to separate catch and finally. Syntetic return
in finally has no any useful meaning. If you want to return from
finally you do it explicitly. catch is another story.

On Mon, Jun 23, 2008 at 1:00 AM, Robert Fischer
<robert.fischer@...> wrote:
> If we *don't* have synthetic returns in catch statements, what would the result of this method call?
>
> def foo() {
>  try {
>    throw new RuntimeException()
>  } catch(Exception e) {
>  }
> }
>
> I'm inclined to being opposed to both try and catch/finally blocks because of flow-of-control
> problems like this: it's tricky to follow.  If you want a synthetic return, capture the return value
> and put it after the try/catch/finally.  Or use an explicit return.
>
> ~~ Robert.
>
> Andres Almiray wrote:
>> +1 on synthetic return in try
>> -1 on synthetic return on catch/finally
>>
>> reason being you write catch/finally because you expect something may go
>> wrong, so I believe you should be very careful in those code sections and
>> leave your expectations unambiguous, i.e., set your returns explicitly.
>>
>>
(Continue reading)

Alexander Veit | 23 Jun 00:26

RE: [groovy-dev] advice needed

> Alex Tkachman wrote:
> ...
> The main problem with try/catch/finally is how should it work.
> ...

In Java there exist two common scenarios:

public Object tryWithoutCatch()
{
 try {
  return getReturnValue();
 }
 finally {
  // do some cleanup
 }
}

public Object tryWithCatch() {
 try {
  return getReturnValueThrowsException();
 }
 catch (Exception e) {
  // handle the error
  return getFallbackValue();
 }
 finally {
  // do some cleanup
 }
}

(Continue reading)


Gmane