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
