• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: SecurityException unchecked or checked?

 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I'm referring to this thread.
In this thread there are two alternatives presented for implementing the
SecurityException:
1. as an unchecked Exception, the well-known java.lang.SecurityException,
arguing that it is bad practice to have the same names of classes even if they are in different packages. And further it is desirable that the caller gets an unchecked exception in this case signalizing that it is an implementation error if a SecurityException is thrown.
2. as an checked Exception, by implementing our own SecurityException. The advantage of this solution consists in the reason that it is also bad practice to include an unchecked exception in the throw-clause, like it has been done in the predefined DBAccess interface.
Further Roel argued:

From the javadoc of java.lang.SecurityException i read :
quote:
---------------------------------------------------------------------------
Thrown by the security manager to indicate a security violation.
---------------------------------------------------------------------------

We are NOT a security manager!

Both alternatives have their advantages and disadvantages.
But I'm thinking of a mixture between both alternatives.
I find the argumentation a SecurityException signalizing an implementation error on part of the client very reasonnable. Thus, I'm thinking to implement my own SecurityException as a subclass of the RuntimeException. The disadvantage of this is that the throw clause contains an unchecked exception. But Sun has sometimes the same practice like at java.lang.Integer#parseInt.
Comments?
Regards
Ulrich
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
nobody seems to take notice of my thread
I would be very thankful for comments
Ulrich
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I might speculate that no one has answered this thread because there is no
one, correct answer.
I suspect, and perhaps others may verify this assertion, that the most
important thing is to be consistent, and to document your design decisions.
But, you already knew this, of course.
Thanks,
Javini Javono
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulrich,
I agree with Javini: none of the possible solutions is perfect. And IMO, all presented choices are defendable.
Just for information, my final decision was to not implement a SecurityException myself, using java.lang.SecurityException instead.
Regards,
Phil.
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini, hi Phil,
thanks for your comments. In a certain way, I assume that I just wanted to hear what both of you were saying to ensure me, thanks
Regards
Ulrich
 
Jacques Bosch
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey.
I went for my own checked SecurityException.
Made more sense to me.
J
 
Liviu Carausu
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I was thinking about defining my own unchecked
suncertify.db.SecurityException.
Using the existing java.lang.SecurityException will contradict with its API definition:
Thrown by the security managerto indicate a security violation.


And using a checked exception with this name will contradict in my opinion with the ideea of SecurityException introduced by Sun. For me it looks like a SecurityException, generally speaking, is not meant to be forced to be catched.

Documenting a unchecked exception is not a problem, as shown in
Integer.valueOf(String s).

What do you think, guys ?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic