better design for catching errors 
July 22nd, 2005, 11:23 AM
| | | better design for catching errors
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.readMethod() == 1) return 1; // called by
class1A.someMethod();
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.someMethod() == 1) break;
}
class3.someMethod();
};
int class1.someMethod()
{
if (class1A.someMethod() == 1) return 1;
};
int class1A.someMethod()
{
if (class1a.someMethod() == 1) return 1;
if (class1B.someMethod() == 1) return 1;
if (class1C.someMethod() == 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 | 
July 22nd, 2005, 11:23 AM
| | | Re: better design for catching errors
"fred" <jcatto@space.qinetiq.com> wrote in message
news:1940ee3f.0405210114.1d63ba23@posting.google.c om...[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 | 
July 22nd, 2005, 11:24 AM
| | | 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.readMethod() == 1) return 1; // called by
> class1A.someMethod();
>
> 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.someMethod() == 1) break;
> }
> class3.someMethod();
> };
>
> int class1.someMethod()
> {
> if (class1A.someMethod() == 1) return 1;
> };
>
> int class1A.someMethod()
> {
> if (class1a.someMethod() == 1) return 1;
> if (class1B.someMethod() == 1) return 1;
> if (class1C.someMethod() == 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] | 
July 22nd, 2005, 11:24 AM
| | | Re: better design for catching errors
"John Harrison" <john_andronicus@hotmail.com> wrote in message news:<2h6012F93mo4U1@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 | 
July 22nd, 2005, 11:24 AM
| | | Re: better design for catching errors
"fred" <jcatto@space.qinetiq.com> wrote in message
news:1940ee3f.0405210114.1d63ba23@posting.google.c om...[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 | | Thread Tools | Search this Thread | | | |
Posting Rules
| You may not post new threads You may not post replies You may not post attachments You may not edit your posts HTML code is Off | | | | | | What is Bytes?
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 220,840 network members.
|