Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project
To: users@groovy.apache.org
References: <576931E8.7000606@gmail.com>
 <CADQzvmnOSQMuaBOHu9ckCzG1FXwuiM3Qz0akRLyhiE6wq+4MvA@mail.gmail.com>
 <5C676E6359909E478C7B811BDB48CA354A6318@CWWAPP478.windstream.com>
 <57696D31.4080604@gmail.com>
 <CADQzvm=_W_duAk0SnNeXXAGoDwwOMEN=tL+qpCN1-rBiHyj0Ag@mail.gmail.com>
 <CAJp1MBOhH3ztZ8Jf4qZKGVfd=tOdPJAtpdck2V6JNRyKonESHQ@mail.gmail.com>
 <5C676E6359909E478C7B811BDB48CA354A6703@CWWAPP478.windstream.com>
 <5769B22E.8070907@gmail.com>
 <CAByu6UXNryXjX6rWcOX7ib63vsRuAFzPiLAsmy0Vh1_UuxosPw@mail.gmail.com>
 <5C676E6359909E478C7B811BDB48CA354A6C16@CWWAPP478.windstream.com>
 <576AC312.5040302@gmail.com> <576ACEB3.9000302@gmx.org>
 <576D5BE2.8000301@gmail.com> <576D9E56.9060807@gmx.org>
 <576F801B.60801@gmail.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <576F9DCD.8020506@gmx.org>
Date: Sun, 26 Jun 2016 11:18:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <576F801B.60801@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Sun, 26 Jun 2016 09:18:20 -0000

On 26.06.2016 09:11, Mr Andersson wrote:
>
>
> On 06/24/2016 10:55 PM, Jochen Theodorou wrote:
>> On 24.06.2016 18:12, Mr Andersson wrote:
>> [...]
>>>> static Groovy is on par most of the time, dynamic Groovy depends, but
>>>> I think it is more in the range of being 2.5 times java (100ms runtime
>>>> becomes 250ms). I think that is close enough.... and there is still
>>>> some potential
>>>
>>> But a Java fork would be almost 1:1, if all it generated was Java like
>>> code.
>>
>> Java like code means to do what Java does. Basically you want a
>> language that includes Java and does things different only in parts,
>> which are not in Java... That means loosing ==, that means loosing our
>> array access logic, that means loosing double dispatch of course..
>> doing builders will become difficult... unless you want to do them
>> like Kotlin. Runtime meta programming basically impossible
>>
>>> I think the performance issues is the invokeDynamic calls that
>>> groovy does internally, and they might not necessarily be needed.
>>
>> there not that many of those, really.
>>
>> [...]
>>> However, any editor could in principle, and in theory tell you on any
>>> call, what exceptions can be thrown and what kind of exceptions you
>>> could choose to handle. Ofcourse that would result in many exceptions
>>> often but the need to declare them on each method is largely syntatical
>>> and ugly.
>>
>> think of a public method and an unknown subclass overriding that
>> method. How can your editor know, that your library method can only
>> throw the exceptions you use in your code and no other? It cannot,
>> unless you make the method final, or say you don´t do libraries ;)
>
> Yes, I also mentioned that case. But since that abstract method either
> has an throws exception declaration on it for specifically stating what
> kind of exception can be thrown, to notify the editor. One should still
> however expect other types of exceptions. The thing is that currently,
> even if an abstract method does not directly state it throws an
> exception type, it can still throw a new RuntimeException(new
> IOException()) so why force the wrapping in the first place?

wrapping is irritating me. The JVM does not really know a difference 
between a checked and a unchecked exception. Thus on the JVM level you 
really do not need to wrap anything.... and in Groovy we do not do that, 
if we can avoid it. In fact I removed lots of wrapped exceptions over 
the years, that have been only required to transport them through the 
runtime for the satisfaction of the java compiler.

> Why force an implementor to either handle an exception type when most of
> the time it doesn't even make sense to do so. If an implementor to a no
> throw exception abstract method, say has to open a file and read it, and
> then return a String, what should that implementor really do to handle
> the IOException? First it happens so rarely that it doesn't make sense
> to handle it, then even if you do handle it, you can only log it. The
> abstract method caller still excepts a response, and you can not abort
> the caller, unless you throw a RuntimeException and hope that he manages
> it, or return null. Why trycatch(Runtime) when you could just as well
> trycatch(Throwable) in this case. You would not need a getCause call to
> figure out if it's wrapped or how many times it has been wrapped.  You
> could also without wrapping trycatch(IOException) directly.

and then your project is also checked with sonar and it wants to force 
you to not just ignore the exception as well.. yeah, I know that pain

> But to be honest, the entire notion of exceptions is kind of broken. An
> IOException is not unique other than by at best it's message, and if one
> decides to bubble an IOException, at some point you will no longer know
> what actually was the root reason if in the call hierarchy as multiple
> places can throw an IOException for various reasons.

but the question is how to make it better. Just making all checked 
exception unchecked won´t solve this.

I know of 3 ways of error handling...

(a) exceptions, like in Java, Python and many other languages
(b) error object or status code as return value, like C for example
(c) using multiple return to transport status code (or error object) as 
well as normal return value.. like Go

I don´t like option b much, but in all cases you need to adapt the 
control flow of your code to the error handling in some way or other.

  bye Jochen