• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Do I need to take care of SecurityException?

 
Can Zheng
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers?

I'm doing the URLyBird assignment and get stuck in the exception handling logic. Hope someone can help me.

The problem is, although in the db interface a SecurityException might be thrown when the cookie provided in delete(), update() or unlock() is not the original cookie returned when calling lock() on the record, it is not possible to happen in my application, unless there is an error in the code. That's because my client code only use lock cookie in the book method which calls lock(), update(), unlock() sequentially and providing a wrong cookie is something not supposed to happen.

So do I still need to take care of SecurityException thrown from these methods? Or simply let it go. I know a RuntimeException can cause something terrible to happen, but this is what ought to happen when there is a mistake like this in the code, right?

Please point out if I missed anything here. Thanks!
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Can,

Thats depend on your design.
I think that you must take of this exception (catch it and rethrow it in other form, or at least to log and leave the method - this very ugly).
If you just ignore it you can get a deadlock/race situation. A bad scenario can be :
client A locks record 1
client B release record 1(exception, but I don't care) -> record1 relase
client B locks record 1
Now Clinent A and B are using the record 1 in the same time.

Regards M.
[ August 07, 2006: Message edited by: Mihai Radulescu ]
 
Can Zheng
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

Your point is of course correct, but maybe I need to make my question a bit clearer.

My concern is, since the client only makes use of update() and unlock(), which potentially throws SecurityException, in the book() method, and the business logic would never result in the SecurityException being thrown. So why do we need to catch it?

Am I missing anything here?
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
it's a checked exception. Checked exceptions need to be either caught or thrown from a method where they can result.
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, People

In specs I don't have a SecurityException but I have something similar in my LockManager, so I agree with Jeroen.

Can,

since the client only makes use of update() and unlock(), which potentially throws SecurityException, in the book() method, ....


You can not assume that the only client which can connect to your Data (server or middle tier) is your client (where the SecurityException is never throw). If you extend you application with new client you can encounter the situation when a SecurityException occurs.

Regards M
 
Can Zheng
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jeroen and Mihai, but I still can not get the reason. Please help me clarify it a bit more.

Hi Jeroen,

it's a checked exception. Checked exceptions need to be either caught or thrown from a method where they can result.


Well, IMHO java.lang.SecurityException extends java.lang.RuntimeException so that it's not a checked exception. Is this SecurityException we are allowed to throw?

and Mihai,

I understand that we need to consider that there are other clients running, but nevertheless, what I insisted is that in my application, a client will always lock before he can update or unlock, and this lock op by its definition should block until a lock is obtained and it never throw SecurityException. So I don't see the reason that considering other clients and even other client apps would change the logic, and thus require this exception be taken care of.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you don't handle an exception, your application will explode in a stacktrace.
You NEVER want that to happen with all but experimental software.

If an exception is explicitly thrown, you should explicitly handle it (even if it's a RuntimeException).

You can assume that the method will in fact throw that exception at some point, so you MUST handle it.
Remember that even if you now control both client and server and can therefore know it will never actually be thrown, it's quite possible that at some stage the server may change and will throw it.
I've built in hooks for user authentication for example in my server and client, which of course means that security exceptions (due to login failures) are a distinct future possibility even if they now are unlikely.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Can Zheng

I made myself the same question a couple of weeks ago when I was working on the lock, update, unlock mechanism.

Actually I handle the suncertify.db.SecurityException. In the catch I simply log the exception. As matter of fact I have comment on top of the log statement that says: this is virtually impossible to happen.

But since suncertify.db.SecurityException is a checked exception you have to do something about it. In my case I do not want to propagate the exception, even less this one, because from a programatic point of view it will never occur. So I simply handled it by means of logging any occurrence of the event, which I am not expecting to happen, but if so, I would really like to know why, so I rather logged it.

That's what I did, it may sound like a good idead to you, too. What do you think?
 
Shan Jun Hao
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The security exception is from java.lang.SecurityException? not an exception class that we build ourself?
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can,

So I don't see the reason that considering other clients and even other client apps would change the logic, and thus require this exception be taken care of.

You make a very serious assumption here, I am not 100 % shore about it.
You can not assume that someone else will follow exact your logic a mistake can be done with purpose(someone highjack you server) or by mistake (most of the
Juniors shame to ask about and they just try to see if it works).
That's why the exceptions are for, to signal you unusual cases.
Take this example :

You can not be 100% shore that the o will be always a non null value.

Edwin,


I think you do the same mistake, with other flavor.
If you only log it you'll make the debug/maintain process more difficult, because your flow fails but is no signal that it fails (only some output in the log
), so your really don't get it that you fail.

Jeroen,
This hook sounds intriguing("hooks for user authentication") can you share/detaliate them, TahnX.

Regards M
[ August 09, 2006: Message edited by: Mihai Radulescu ]
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mihai, I strongly believe that from the programatic point of view it is impossible to happen:



In the code above I do not see a way by means of which the unlock method may receive a wrong cookie and throw a SecurityException. Therefore I say it will never happen. You could log it, as I do, rethrow the exception or wrap the exception into a more specific exception.

Shan, you know that unchecked exception are never declared in the method signatures. Well, java.lang.Security exception is an unchecked exception. Therefore I assumed the one declared in the DBAccess interface is not this one and I declared my one suncertify.db.SecurityException.

You must be careful if you do this, because java.lang.SecurityException is imported by default since it is in the java.lang package.

Regards,
ED.
[ August 09, 2006: Message edited by: Edwin Dalorzo ]
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Shan Jun Hao:
The security exception is from java.lang.SecurityException? not an exception class that we build ourself?


IMO it's supposed to be a checked exception and therefore you have to create it as the standard library SecurityException is a RuntimeException.

RuntimeExceptions are not supposed to be added to the throws clause of a method according to almost every best practice and coding standards document in existence (you'd have to check the Sun standards to see if they explicitly say so though).
And because the exception IS explicitly mentioned, that means to me it is a checked exception.
 
Khaled Mahmoud
Ranch Hand
Posts: 361
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First I have a note on the name of the exception:
The exception name provided by the specification is SecurityException not for example ConcurrentAccessException or something like that.Why Sun chose to call that exception SucurityException.
I agree with everyone who said that this exception is not supposed to happen in the logic of the application.Because the only way this exception can occur is that two clients book the same record,which if happend this means that the locking mechanism have some pitfalls.
My idea is that someone may be trying to access a record that you already accessing (booked)and this will lead to a SecurityException.How can someone try to access a record that you are already accessing i have no idea.
For what Mihai said


client A locks record 1
client B release record 1(exception, but I don't care) -> record1 relase
client B locks record 1
Now Clinent A and B are using the record 1 in the same time.

This case depends on the long value returned from the lock method.For example if the lock value was the same as the record number or something that is dependent on the record number (calculater from the record number) it would be so easy for anyone to gain access to a booked record because he know the record number.I imagine this will play a greater role in future enhacements than in the current version of the application.
I agree with everyone who said that this should be a checked exception not a runtime exception.I beleive runtime exception should be for something we cannot control like hardware failure...etc.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic