Improvement in handling exception

[Daniel.Sun]

Hi all,

"the Groovy methods will not declare that they throw any checked exceptions unless you’ve explicitly added the
declaration, even though they might throw checked exceptions at runtime." quoted from 'Groovy in Action'

I think Groovy should compel programmers to add 'throws XXXException' explicitly as Java do when defining a method that can throw some exception.

Why do I think it very vital?
For example,
If I define an exception of my own.

class MyException extends Exception {
  MyException(String msg) {
    super(msg)
  }
}

then I instantiate MyException and throw it in myMethod1

def myMethod1() {
  throw new MyException("error root")
}

then I invoke myMethod1 in myMethod2

def myMethod2() {
  //... omit
  myMethod1()
  //...omit
}

//...invoke myMethodx() in myMethody()

At last I invoke myMethody in myMethodn which is vital for our application and should be robust and shouldn't crash.
but I can NOT remember that myMethody can throw MyException. What is worse, I have NOT enclosed "myMethody()" in try-catch clause. Disaster appeared :(  myMethodn will crash in some day.

def myMethodn() {
   //... omit
  myMethody()
  //...omit
}


Best regards,
Daniel.Sun

[tugwilson]

On 8 Feb 2007, at 06:11, Daniel.Sun wrote:

> Hi all,
>
> "the Groovy methods will not declare that they throw any checked  
> exceptions
> unless you’ve explicitly added the
> declaration, even though they might throw checked exceptions at  
> runtime."
> quoted from 'Groovy in Action'
>
> I think Groovy should compel programmers to add 'throws XXXException'
> explicitly as Java do when defining a method that can throw some  
> exception.
>
> Why do I think it very vital?
> For example,
> If I define an exception of my own.
>
> class MyException extends Exception {
>   MyException(String msg) {
>     super(msg)
>   }
> }
>
> then I instantiate MyException and throw it in myMethod1
>
> def myMethod1() {
>   throw new MyException("error root")
> }
>
> then I invoke myMethod1 in myMethod2
>
> def myMethod2() {
>   //... omit
>   myMethod1()
>   //...omit
> }
>
> //...invoke myMethodx() in myMethody()
>
> At last I invoke myMethody in myMethodn which is vital for our  
> application
> and should be robust and shouldn't crash.
> but I can NOT remember that myMethody can throw MyException. What  
> is worse,
> I have NOT enclosed "myMethody()" in try-catch clause. Disaster  
> appeared :(
> myMethodn will crash in some day.
>
> def myMethodn() {
>    //... omit
>   myMethody()
>   //...omit
> }

The debate about checked vs unchecked exceptions is very old. Java  
has checked exceptions (put into the language at the very last  
minute), C# does not. There have been many discussions about the  
robustness of C# applications vs Java ones due to this difference. In  
practice there seems not to be any difference.

We took a decision right at the start of the project not to require  
users to do housekeeping of checked exceptions and this seems to work  
very well.

I do, however, think that  we could improve our Exception handling  
whit respect to Java interfacing. If a groovy method throws a checked  
exception but does not have a throws clause then a Java method which  
calls it cannot catch the exception. The Groovy compiler can tell  
that a checked exception is thrown and could, in principle, put the  
throws clause into the generated bytecode.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Daniel.Sun]

Thank you for your patient response.
Maybe I program in Java for a long time, so something groovy I can't understand and meet troubles half-way :)

John Wilson wrote:

On 8 Feb 2007, at 06:11, Daniel.Sun wrote:

> Hi all,
>
> "the Groovy methods will not declare that they throw any checked  
> exceptions
> unless you’ve explicitly added the
> declaration, even though they might throw checked exceptions at  
> runtime."
> quoted from 'Groovy in Action'
>
> I think Groovy should compel programmers to add 'throws XXXException'
> explicitly as Java do when defining a method that can throw some  
> exception.
>
> Why do I think it very vital?
> For example,
> If I define an exception of my own.
>
> class MyException extends Exception {
>   MyException(String msg) {
>     super(msg)
>   }
> }
>
> then I instantiate MyException and throw it in myMethod1
>
> def myMethod1() {
>   throw new MyException("error root")
> }
>
> then I invoke myMethod1 in myMethod2
>
> def myMethod2() {
>   //... omit
>   myMethod1()
>   //...omit
> }
>
> //...invoke myMethodx() in myMethody()
>
> At last I invoke myMethody in myMethodn which is vital for our  
> application
> and should be robust and shouldn't crash.
> but I can NOT remember that myMethody can throw MyException. What  
> is worse,
> I have NOT enclosed "myMethody()" in try-catch clause. Disaster  
> appeared :(
> myMethodn will crash in some day.
>
> def myMethodn() {
>    //... omit
>   myMethody()
>   //...omit
> }


The debate about checked vs unchecked exceptions is very old. Java  
has checked exceptions (put into the language at the very last  
minute), C# does not. There have been many discussions about the  
robustness of C# applications vs Java ones due to this difference. In  
practice there seems not to be any difference.

We took a decision right at the start of the project not to require  
users to do housekeeping of checked exceptions and this seems to work  
very well.

I do, however, think that  we could improve our Exception handling  
whit respect to Java interfacing. If a groovy method throws a checked  
exception but does not have a throws clause then a Java method which  
calls it cannot catch the exception. The Groovy compiler can tell  
that a checked exception is thrown and could, in principle, put the  
throws clause into the generated bytecode.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 8 Feb 2007, at 09:23, Daniel.Sun wrote:

> Thank you for your patient response.
> Maybe I program in Java for a long time, so something groovy I can't
> understand and meet troubles half-way :)


it's no problem:)

I always have a period when moving from programming language X to  
programming language Y of saying "In X we do this why can't I do it  
in Y?". In the end I understnad Y's way of doing things!


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Daniel.Sun]

Yeah, you're right.
I will take more time in studying Groovy which is really very wonderful programming language.
I love it very much :)

John Wilson wrote:

On 8 Feb 2007, at 09:23, Daniel.Sun wrote:

> Thank you for your patient response.
> Maybe I program in Java for a long time, so something groovy I can't
> understand and meet troubles half-way :)


it's no problem:)

I always have a period when moving from programming language X to  
programming language Y of saying "In X we do this why can't I do it  
in Y?". In the end I understnad Y's way of doing things!


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Paul King]

John Wilson wrote:

>
> On 8 Feb 2007, at 06:11, Daniel.Sun wrote:
>> [...] I think Groovy should compel programmers to add 'throws XXXException'
>> explicitly as Java do when defining a method that can throw some
>> exception.
>
> The debate about checked vs unchecked exceptions is very old. Java has
> checked exceptions (put into the language at the very last minute), C#
> does not. There have been many discussions about the robustness of C#
> applications vs Java ones due to this difference. In practice there
> seems not to be any difference.

I would present the issues in a different (and much less succinct)
way than John but reach very similar conclusions...

There are those that despise checked exceptions (it makes TDD harder
in Java) and those that argue the benefits. The balanced view for Java
is that checked exceptions should be used when you can reasonably expect
that the caller can and wants/needs to be able to respond to an error
situation. The implication of this is that for nearly any general purpose
library checked exceptions are not usually the way to go because you
can't (in general) always know that a user of your library wants to
respond to your errors. There are many places in Java which don't obey
this rule. Groovy's design choices makes using such classes have much
less scaffolding code and makes various kinds of testing both possible
and relatively easy. You can add the relevant try/catch code if you
wish.

Now, arguments for using checked exceptions within your application
are much stronger. There they can be much more beneficial and you can
reasonably expect that parts of your application code can make expectations
about how other parts can/should use exceptions. Even so, if you refactor
your code into general purpose libraries, you will probably keep checked
exceptions out of the reusable parts. What you will have left - the places
were checked exceptions prove most beneficial should really only be a
small number of layers. Groovy doesn't help in this case but there is
no reason why good IDE support couldn't detect such scenarios.

Paul.




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

    http://xircles.codehaus.org/manage_email

[Russel Winder]

On Thu, 2007-02-08 at 09:54 +0000, John Wilson wrote:

> I always have a period when moving from programming language X to  
> programming language Y of saying "In X we do this why can't I do it  
> in Y?". In the end I understnad Y's way of doing things!

Back to Marion's thesis :-)

Don't forget though the situation:

I am moving from language X to language Y, I do this thing this way in X
why can't I do it this way in Y.  Ah you do it that way in Y, but isn't
that ludicrous?  If I did it this way in Y learning a lesson from the
way it is done in X then doesn't that work even better in Y?  Oh yes.

This is why I like working in multiple languages at all times, the
cross-fertilization of idioms makes for much better programs in all
languages.

--
Russel.
====================================================
Dr Russel Winder                [phone]
41 Buckmaster Road              [phone]
London SW11 1EN, UK             russel@...

[Russel Winder]

I very much agree with Paul's comments, but I would take a stronger
line:

I think that checked exceptions thrown by library / infrastructure are a
mechanism for the library / infrastructure implementer to control the
way in which an application is to be programmed, i.e. to limit the
freedom of the application developer to design and implement the
application as they want to do.

I find the fascism of checked exceptions issued by libraries /
infrastructure to be extremely constraining -- and if you see any of my
C++ or Java code you will see I am a huge fan of massive static type
checking, and use of cosnt/final everywhere to ensure single assignment
semantics wherever possible (arguably I overdo it :-).

Personally I can see no use for checked exceptions except where the
throwing and catching are always entirely within the code I write.

On Thu, 2007-02-08 at 20:34 +1000, Paul King wrote:

> There are those that despise checked exceptions (it makes TDD harder
> in Java) and those that argue the benefits. The balanced view for Java
> is that checked exceptions should be used when you can reasonably expect
> that the caller can and wants/needs to be able to respond to an error
> situation. The implication of this is that for nearly any general purpose
> library checked exceptions are not usually the way to go because you
> can't (in general) always know that a user of your library wants to
> respond to your errors. There are many places in Java which don't obey
> this rule. Groovy's design choices makes using such classes have much
> less scaffolding code and makes various kinds of testing both possible
> and relatively easy. You can add the relevant try/catch code if you
> wish.
>
> Now, arguments for using checked exceptions within your application
> are much stronger. There they can be much more beneficial and you can
> reasonably expect that parts of your application code can make expectations
> about how other parts can/should use exceptions. Even so, if you refactor
> your code into general purpose libraries, you will probably keep checked
> exceptions out of the reusable parts. What you will have left - the places
> were checked exceptions prove most beneficial should really only be a
> small number of layers. Groovy doesn't help in this case but there is
> no reason why good IDE support couldn't detect such scenarios.

--
Russel.
====================================================
Dr Russel Winder                [phone]
41 Buckmaster Road              [phone]
London SW11 1EN, UK             russel@...

[Jochen Theodorou]

John Wilson schrieb:
[...]
> I do, however, think that  we could improve our Exception handling whit
> respect to Java interfacing. If a groovy method throws a checked
> exception but does not have a throws clause then a Java method which
> calls it cannot catch the exception.

a reason to declare that Exception in the throws clause

> The Groovy compiler can tell that a
> checked exception is thrown and could, in principle, put the throws
> clause into the generated bytecode.

sure yes... when I move the exception throwing code into another method,
then what? I don't think we should do that... too much magic and for
APIwriters it is a bad thing to have these Exceptions in there without
their knowledge. And if I write a method m1 that calls a method m2 that
throws a checked exception e1 and if I call this method m1, then how do
I catch e1? When I think about IOEceptions, then I think it is not
reasonable to automatically put anything into the method signature, that
is not decided by the programer.

bye blackdrag


--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

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

    http://xircles.codehaus.org/manage_email