better design for catching errors

[fred]

Hello,

I have a program that reads from a file at several different places. I
want to find when the file hits the EOF. At this point I want to tell
the calling method that this has happened so that the program can move
onto the next phase.

My class hierarchy is something like:
main() -> class1 -> class1A -> class1a
-> class1B
-> class1C
-> class2 -> class2A -> class2a
-> class3

Class1a, class1B and class1C all read the same file.
When the file is finished with, control must be passed to class3.

At present I pass this message by using 'return 1;' from the read
method of classes 1a, 1B, 1C and checking the status of this method
using for example:
if (class1a.readMe thod() == 1) return 1; // called by
class1A.someMet hod();

The problem I am facing is that the calling class (class1A above),
which checks the status, is not the same class as that which
determines whether the program continues beyond the file read
(class1).
Therefore, as shown below, I have to pass this message up several
classes from the read method in the bottom class to the control method
in the top class, i.e. continually returning 1 if the method of the
subclass returned 1.

Also, since I read the file from several different classes, I must do
this message passing from several points through the hierarchy.

main()
{
while(true)
{
if (class1.someMet hod() == 1) break;
}
class3.someMeth od();
};

int class1.someMeth od()
{
if (class1A.someMe thod() == 1) return 1;
};

int class1A.someMet hod()
{
if (class1a.someMe thod() == 1) return 1;
if (class1B.someMe thod() == 1) return 1;
if (class1C.someMe thod() == 1) return 1;
};

As you can see, this is very messy.

Can anyone suggest a better design for this kind of system?
Perhaps a error handling class, called if EOF is reached, which
returns control to a strategic point? I just can't see it...

thanks
Fred

[John Harrison]

Re: better design for catching errors


"fred" <jcatto@space.q inetiq.com> wrote in message
news:1940ee3f.0 405210114.1d63b a23@posting.goo gle.com...[color=blue]
> Hello,
>
> I have a program that reads from a file at several different places. I
> want to find when the file hits the EOF. At this point I want to tell
> the calling method that this has happened so that the program can move
> onto the next phase.
>[/color]

[snip]
[color=blue]
>
> As you can see, this is very messy.
>
> Can anyone suggest a better design for this kind of system?
> Perhaps a error handling class, called if EOF is reached, which
> returns control to a strategic point? I just can't see it...
>[/color]

Didn't you ask this before?

Throw an exception, returning control to a strategic point is exactly what
exceptions are designed for.

john

[Shashank]

Re: better design for catching errors

Hi Fred,

What you need to do is that let the calling class subscribe for EOF event.
When the EOF is hit, call back on it to inform that EOF is reached.

Now you calling program can write the code inside that call back method to
execute its behavior.

regards,
Shashank

fred wrote:
[color=blue]
> Hello,
>
> I have a program that reads from a file at several different places. I
> want to find when the file hits the EOF. At this point I want to tell
> the calling method that this has happened so that the program can move
> onto the next phase.
>
> My class hierarchy is something like:
> main() -> class1 -> class1A -> class1a
> -> class1B
> -> class1C
> -> class2 -> class2A -> class2a
> -> class3
>
> Class1a, class1B and class1C all read the same file.
> When the file is finished with, control must be passed to class3.
>
> At present I pass this message by using 'return 1;' from the read
> method of classes 1a, 1B, 1C and checking the status of this method
> using for example:
> if (class1a.readMe thod() == 1) return 1; // called by
> class1A.someMet hod();
>
> The problem I am facing is that the calling class (class1A above),
> which checks the status, is not the same class as that which
> determines whether the program continues beyond the file read
> (class1).
> Therefore, as shown below, I have to pass this message up several
> classes from the read method in the bottom class to the control method
> in the top class, i.e. continually returning 1 if the method of the
> subclass returned 1.
>
> Also, since I read the file from several different classes, I must do
> this message passing from several points through the hierarchy.
>
> main()
> {
> while(true)
> {
> if (class1.someMet hod() == 1) break;
> }
> class3.someMeth od();
> };
>
> int class1.someMeth od()
> {
> if (class1A.someMe thod() == 1) return 1;
> };
>
> int class1A.someMet hod()
> {
> if (class1a.someMe thod() == 1) return 1;
> if (class1B.someMe thod() == 1) return 1;
> if (class1C.someMe thod() == 1) return 1;
> };
>
> As you can see, this is very messy.
>
> Can anyone suggest a better design for this kind of system?
> Perhaps a error handling class, called if EOF is reached, which
> returns control to a strategic point? I just can't see it...
>
> thanks
> Fred[/color]

[puppet_sock@hotmail.com]

Re: better design for catching errors

"John Harrison" <john_andronicu s@hotmail.com> wrote in message news:<2h6012F93 mo4U1@uni-berlin.de>...
[snip][color=blue]
> Throw an exception, returning control to a strategic point is exactly what
> exceptions are designed for.[/color]

Exceptions can be used that way. But generally, the "designed for"
purpose of exceptions is richer than that. Usually, what you want
to use an exception for is what its name suggests, to deal with
the siutations where the contract of the interface can't be met.

So, if the interface of a class specifies that it looks for the
end of file, and returns a value through the regular interface
indicating that, then probably you don't want that as an exception.
But if the interface specs that it is not supposed to encounter
the end of the file during operation, and can't succeed if it
does, then it should throw an exception in that case.

So, to restate the rule: If the class completes a task within
the specified rules, it should indicate that through the regular
interface. If it can't satisfy the requirements specified, then
it should throw an exception.

This is not a "hard and fast" rule, not a religious decree.
There are times and places to break this rule, as with many
software design rules. But probably the original poster's
problems arise from crummy design rather than lack of use
of exceptions.
Socks

[Jeff Flinn]

Re: better design for catching errors


"fred" <jcatto@space.q inetiq.com> wrote in message
news:1940ee3f.0 405210114.1d63b a23@posting.goo gle.com...[color=blue]
> Hello,
>
> I have a program that reads from a file at several different places. I
> want to find when the file hits the EOF. At this point I want to tell
> the calling method that this has happened so that the program can move
> onto the next phase.[/color]

Sounds remotely like a parsing task. See
http://www.boost.org/libs/spirit/index.html. As the file is read, objects
are constructed. Constructors can calculate and set their own state
variables.

What is a higher level description of what you are trying to do?

Jeff F