groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Is it possible to enable CompileStatic for an entire project
Date Sun, 26 Jun 2016 09:18:05 GMT
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

View raw message