Sorry about the long explanation that is completely unrelated to this
special case but I think the discussion checked vs unchecked exceptions
is a general thing so I write a general reasoning...
In general checked Exceptions force the user of an API to handle an
exception at exactly the point where it happens.
Often thoughit is much easier to let an exception bubble up the stack to
a general place where exceptions are handled. Checked exceptions also
force to Map an exception at every layer of an application. The reason
is that simply throwing exceptions over layer boundaries violates
encapsulation.
So my way of handling checked exceptions is: where they are forced upon
me by an API I map them to an unchecked Exception as soon as possible to
limit their effect / damage.
I have found a nice explanation on this article
http://www.javacodegeeks.com/2012/03/why-should-you-use-unchecked-exceptions.html
In his famous book, *Clean code: a handbook of agile software
craftsmanship*[3
<http://books.google.co.in/books/about/Clean_code.html?id=dwSfGQAACAAJ&redir_esc=y>],
Robert C. Martin writes the below lines supporting Unchecked Exceptions.
/The debate is over. For years Java programmers have debated over the
benefits and liabilities //of checked exceptions. When checked
exceptions were introduced in the first version //of Java, they seemed
like a great idea. The signature of every method would list all of the
//exceptions that it could pass to its caller. Moreover, these
exceptions were part of the type/
/of the method. Your code literally wouldn't compile if the signature
didn't match what your //code could do./
/
/
/At the time, we thought that checked exceptions were a great idea;
and yes, they can //yield some benefit. However, it is clear now that
they aren't necessary for the production of //robust software. C#
doesn't have checked exceptions, and despite valiant attempts, C++
//doesn't either. Neither do Python or Ruby. Yet it is possible to
write robust software in all //of these languages. Because that is the
case, we have to decide---really---whether checked //exceptions are
worth their price./
/
/
Here some more similar articles:
http://tapestryjava.blogspot.in/2011/05/tragedy-of-checked-exceptions.html
http://blogs.atlassian.com/2011/05/exceptions_are_bad/
http://misko.hevery.com/2009/09/16/checked-exceptions-i-love-you-but-you-have-to-go/
Christian
Am 01.02.2013 14:36, schrieb Francesco Chicchiriccò:
On 01/02/2013 14:33, Andrei Shakirin wrote:
Hi Francesco,
I thought it was agreed in [1]. Have seen no objections in [2].
You're right about [1] and [2] - only, I have just realized now,
working on SYNCOPE-136, that ignoring this exception can be very
dangerous during the propagation process. And having it checked helps
definitely in this sense.
Do you have reasons to keep this exception checked?
Let's put it the other way round: why have it unchecked?
Regards.
[1]
https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions
[2]
http://syncope-dev.1063484.n5.nabble.com/Exception-propagation-in-Rest-interface-HTTP-header-vs-body-for-details-td5711482.html
-----Original Message-----
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Freitag, 1. Februar 2013 14:12
To: dev@syncope.apache.org
Subject: IncompatiblePolicyException was made unchecked
Hi all,
I've just noticed that IncompatiblePolicyException, created checked
[1] is
now unchecked: any reason for this?
[1]
http://svn.apache.org/viewvc/incubator/syncope/trunk/core/src/main/java
/org/apache/syncope/core/util/IncompatiblePolicyException.java?view=mar
kup&pathrev=1401200
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
