groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mr Andersson <>
Subject Re: Is it possible to enable CompileStatic for an entire project
Date Sun, 26 Jun 2016 07:11:23 GMT

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?

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.

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.

I am just saying that just as there are many types of RuntimeExceptions 
that can happen, and one would have to handle them anyway, not knowing 
what they are, the checked exceptions should really be treated the same 
way as they too, despite checked, can be wrapped as Runtime but in fact, 
they are not really unchecked ones.

> bye Jochen

View raw message