Modifying code for exceptions

[Bruce Harden]

Hi:

I want to modify code, with method calls:

A > B > C > D ( eg method A calls B ; method B calls C; etc.)
A_Prime > B > C > D


Want to throw an exception in D -- to propogate up to A
but do NOT want to throw an exception in D -- to propogate up to A_Prime

eg, so it changes D to D_Prime throws <some exception>

A > B > C > D_Prime

A_Prime > B > C > D (stays same, with out throwing exception)


If I modify code to add a parm when calling B from A, that is not used when calling B from A_Prime, its easy enough to modify:

For instance:

change so A calls B with newParm & old Parm list

change so A_Prime calls B with a (dummy newParm) & old Parm list

and propagate down the call stack fairly painlessly


but in the above scenario where one path is changing to throw an exception, but another isn't
is there an easy way to do that?

Eg, <A, A_Prime, B, C> code is NOT changing.

D has a slight change so that it can call a method that can throw an exception when called indirectly by A

It seems a pretty big pain to change so the A_Prime > B > C > D path does NOT throw an exception
but A > B > C > D DOES throw an exception.

I could put throws clauses in A_Prime > B > C > D path but would prefer to avoid -- just because I imagine looking at it
in future would be confusing when there is no chance of an exception from that path.

At least to me, checking the (dummy newParm) is "self-documenting" and fairly straight forward -- but it may just because
I have a lot of experience with that kind of changes. I am more inexperienced with exceptions.

Maybe throwing exceptions in A_Prime > B > C > D path is SOP, but I would like to see if someone more experienced
has a better solution.


I googled the following w/o finding any good insights:

java method one path throws exception one does not
java one path throw modify old code
java throw "modify old code"
java throw


Thanks in advance!

[Paul Clapham]

I'm not sure what that is all about; but if you're saying that you may or may not want to throw an exception depending on where your code was called from, then that would mean there's something wrong with your design.

However it's impossible to tell what your design is about because you have given your methods opaque names like "B". Perhaps you could take a step back and explain your actual use case which requires context-sensitive exception throwing.

[Bruce Harden]

Ok, here is the context:

I have one application and another applet reading a config file, using the same code in a package.

The applet reads it very quickly because it does nothing but read it.

The application does it much more slowly, because it reads it plus does a lot of database operations
in addition to reading, since these database operations could affect the GUI that is presented
to user that reflects the config file.

Because the application could take a long time, I present an option to the user to cancel.

The cancel works by sending an interupt & the application read is done within a swingworker.

The application read does sleep(0) at quick intervals. These will trigger an interupt exception
that will terminate the application read, if user cancels.

Because the applet goes much quicker, I don't have the cancel option (And I don't want to put
sleep(0) in its code because I imagine a browser could send an interupt).

This might not be the best design, but it is my initial thought to implement a cancel option
in the application. So the application throws exceptions, but the applet does not.

The config file read is solid code and is shared between the application & applet. The above
approach is what I think would be a way to add an application cancel of config read with
minimal changes, but I am certainly open to other approaches.

I'm currently away from my home PC, & thus can't post a code sample, but I could later if
this is unclear.

[Paul Clapham]

Okay... so the code in the application will throw an exception if it's interrupted. And you have the same code in the applet, right? Only there isn't any possibility that it will ever be interrupted? If so then I don't see the problem. The code should simply throw the exception if it's interrupted. The applet won't ever interrupt it, which just means that exception won't ever be thrown in the applet context.

I was under the impression that you wanted the code to act differently when the applet and the application did the same thing. That indeed would be a strange design. But that isn't the case, because the applet and the application don't do the same thing.