• Post Reply Bookmark Topic Watch Topic
  • New Topic

Inheritance and Exception Handling  RSS feed

 
H Melua
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello

I have 4 classes
1 - Main
2 - Parent
3 - Child
4 - Helper

The order of execution is this
main >>> Helper.do() >>>Parent.requested() >>> child.overrideMethod()

The Parent class looks like this


the Child class extends the Parent, and implements another interface, note that the do() method belongs to the Helper interface and not the parent



now what happens here is that when the "out of memory" exception is thrown from the Child class, it is caught in the Helper.do() method, not the Parent.requested() method...
I thought when the overrideMethod() throws the exception it will be still running inside the requested() method... and the exception will be caught there

I want the exception to be handled in the Parent.requested() method not the Helper.do().

Thanks
HannaH
[ September 13, 2008: Message edited by: H Melua ]
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
now what happens here is that when the "out of memory" exception is thrown from the Child class, it is caught in the Helper.do() method, not the Parent.requested() method...


That is not how the code you provided works.

1) Your do method never catches an exception
2) As described above, the exception will always be caught in the requested() method. Here is my test code:


The same code you provided with some modifications (make sure the SecurityException is thrown, change do() to work() since do is a reserved word, take file.delete out as I don't have a file to delete).

When you run the code you will see that the parent is always catching the error.

Your problem is that you are probably getting a second exception in the requested() method because you are doing a file.delete(). My guess is anytime you get a SecurityException in the Child class, you would also get a SecurityException when trying to delete a file.

Part of the problem is that you are passing a specific exception (SecurityExcpetion) as the general Exception, which is bad. You are then catching the general Exception, which is bad, and trying to do the same action no-matter what the original problem was, which is bad. If you know that a SecurityException is thrown from the overrideMethod, for example, you would know you weren't able to delete the file, and so could avoid causing another exception while trying to cleanup after the first.

At very least you would need to take care of the case where a SecurityException occurs when you attempt to delete the file. Or expect to pass that information along to the calling method if you can't expect to fix it.
[ September 13, 2008: Message edited by: Steve Luke ]
 
H Melua
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you so much Steve for taking the time to correct things..
I think thats what was going wrong
Originally written by Steve
Your problem is that you are probably getting a second exception in the requested() method because you are doing a file.delete().

I made a design mistake when making the work() method inside an untrusted class (Child)

you see I know the child will throw an exception (and I am expecting it to do so), but I wanted to test something... If I move the work() method and place it inside a trusted class then the file eventually gets deleted after the first security exception is thrown! which is something a programmer certainly doesn't want... the fact the operation does not "always" halt when the bad code influenced the execution is not desirable...
and it indeed deleted the file!

I totally agree that i made many wrong decisions, but they are intentional because i know many programmers are not perfect and such mistake in complex code can occur...

anyway, my testing was successful...
Thanks a lot for your help
HannaH
[ September 13, 2008: Message edited by: H Melua ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!