Re: Raising Exceptions Vs returning erro[Ref:C809787]

Question

Hi Steve !
Probably the following explanation might help in resolving the issue raised by
you:
At a more abstract level, there is only one thing, i.e. the EVENT. According to
it's definition, an event is a relatively infrequent occurrence in one portion (lets
call it event raiser) of the application, which some other portion (or portions,
lets call them event handlers) (of the same application) are interested to respond
to it. Now there are two scenarios:
(A) Event raiser and Event handler(s) are being executed under different threads
of control (Asynchronous) and
(B) Event raiser and Event Handler(s) are being executed under same thread of
control (Synchronous).
So, Exception Handling belongs to scenario B where the method raising the
exception (Event Raiser or exception raiser) and the method handling it (Event
Handler or exception block) are under the same thread of control. More ever it has
to be insured that at a time only one handler (first the inner most one) receives
the message.
Forté provides a generic Event handling mechanism (Post Event and Event Loop) to
handle the scenario A (which is the more generic one). But it also provides a
specialized Event Handling mechanism (Raise Exception and Exception block) to
efficiently handle the relatively simple scenario B. Why I am saying that the later
is efficient because it won't be needing to register the event queue address of the
interested task (after all there is only one task involved) and put the event
message in queue.
Finally let me mentioned that it is just my view based on the understanding I
have and it may not be true. Only a person from forté can confirm it. I will really
appreciate if somebody correct and or refine it.
Wish a Very Very Happy New Year to all Forté Users
Regard,
Kailash.
[email protected] wrote:
I would agree with Eric entirely. Exceptions seem to me to be a much more
complete solution to the problem of error handling. A little bit of effort up
front in making clear the strategy for exception handling and specifying the
exceptions that can be raised by a class\method will provide an excellent method
for error handling.
In the case of ensuring exceptions are always handled, a top level handler for
GenericException will usually do the job, allowing you to write error
information out to logs, screen, etc, and then shut down gracefully.
The only issue I would raise with exceptions is that they are not propagated
outside an asynchronous task. If an exception is not handled within an
asynchronous, it will not propagate to the task that started that asynchronous
task. Forte provides return and exception events when starting asynchronous
tasks to cope with this, but it seems a shame to have one method of dealing with
errors (exceptions) for synchronous behaviour, and another (events) for
asynchronous behaviour.
Steve Elvin
Systems Developer
Frontline Ltd.
UK
Mark,
The problem with return codes is that there is an underlying assumption
that the receiver will always catch and interpret that error code. This
may or may not be good thing, depending on how you architect your
application. If, on the other hand, you want to ensure that an error is
always handled, if not by the receiver then by the Forte, Exceptions are
the way to go. To extend this mechanism further, I would subclass
GenericException and created my own error code attribute on that
subclass. That way the receiver has the choice of interpreting the
exception based on that error code, and wrapping it in a
MessageDialog/window or do the usual 'errormgr.showerrors()'.
Exceptions seem a more flexible approach to me. That is, if you can live
with the fact that by using it, you're violating the 'exceptions for
behavioral anomalies' software engineering principle !
Best wishes.
Eric Pereira
Forte Consultant
----Original Message Follows----
From: "Kallambella, Ajith" <[email protected]>
To: "'Mark Sundsten'" <[email protected]>, [email protected]
Cc: [email protected]
Subject: RE: Raising Exceptions Vs returning error codes
Date: Wed, 30 Dec 1998 08:52:39 -0500
Reply-To: "Kallambella, Ajith" <[email protected]>
Mark,
Identifying conditions where you would rather use an exception
to an error_code ( and vice-versa ) normally depends on
your application design. Usually exceptions
are used to handle behavioral anomalies which are
not expected during the normal course of execution of
the program, and which would affect the continuity of
your algorithm if ignored. Examples would be a fatal
error, a semantically invalid( but syntactically-valid
token ) etc.
Error_codes and return status's can be used to handle
anticipated and recoverable errors. Example would
be presentation layer validations. In any normal
UI system, the user is expected to make errors and it
would be annoying to throw an exception( and to handle
it ), every time user enters wrong data. A well
modeled client layer should not only handle
data-validation errors , but should be smart enough
to encourage users to input correct or
"near-correct" data. Examples could be
making use of look-up windows etc. Interestingly,
Express uses exceptions to handle data-validations.
As you see, exceptions fit well into your processing
logic where severity of damage caused by an error
is more. Where as error_codes fit well into presentation
logic( and some not-so-critical processing logic ) where
errors are usually recoverable and normal path of
execution can be easily restored.
Hope this helps. I would be very interested to hear
what others have to say.
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Mark Sundsten [mailto:[email protected]]
Sent: Tuesday, December 29, 1998 2:10 PM
To: [email protected]
Cc: [email protected]
Subject: Raising Exceptions vs returning error codes
When dealing with error handling, I find myself struggling with the
choice
of
raising exceptions (and handling them) from the caller
vs returning an error code of somekind.
When would you want to use one over the other?
Should you always use exception handling?
Any discussion would be appreciated.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Answer 1

Hi Steve !
Probably the following explanation might help in resolving the issue raised by
you:
At a more abstract level, there is only one thing, i.e. the EVENT. According to
it's definition, an event is a relatively infrequent occurrence in one portion (lets
call it event raiser) of the application, which some other portion (or portions,
lets call them event handlers) (of the same application) are interested to respond
to it. Now there are two scenarios:
(A) Event raiser and Event handler(s) are being executed under different threads
of control (Asynchronous) and
(B) Event raiser and Event Handler(s) are being executed under same thread of
control (Synchronous).
So, Exception Handling belongs to scenario B where the method raising the
exception (Event Raiser or exception raiser) and the method handling it (Event
Handler or exception block) are under the same thread of control. More ever it has
to be insured that at a time only one handler (first the inner most one) receives
the message.
Fort&eacute; provides a generic Event handling mechanism (Post Event and Event Loop) to
handle the scenario A (which is the more generic one). But it also provides a
specialized Event Handling mechanism (Raise Exception and Exception block) to
efficiently handle the relatively simple scenario B. Why I am saying that the later
is efficient because it won't be needing to register the event queue address of the
interested task (after all there is only one task involved) and put the event
message in queue.
Finally let me mentioned that it is just my view based on the understanding I
have and it may not be true. Only a person from fort&eacute; can confirm it. I will really
appreciate if somebody correct and or refine it.
Wish a Very Very Happy New Year to all Fort&eacute; Users
Regard,
Kailash.
[email protected] wrote:
I would agree with Eric entirely. Exceptions seem to me to be a much more
complete solution to the problem of error handling. A little bit of effort up
front in making clear the strategy for exception handling and specifying the
exceptions that can be raised by a class\method will provide an excellent method
for error handling.
In the case of ensuring exceptions are always handled, a top level handler for
GenericException will usually do the job, allowing you to write error
information out to logs, screen, etc, and then shut down gracefully.
The only issue I would raise with exceptions is that they are not propagated
outside an asynchronous task. If an exception is not handled within an
asynchronous, it will not propagate to the task that started that asynchronous
task. Forte provides return and exception events when starting asynchronous
tasks to cope with this, but it seems a shame to have one method of dealing with
errors (exceptions) for synchronous behaviour, and another (events) for
asynchronous behaviour.
Steve Elvin
Systems Developer
Frontline Ltd.
UK
Mark,
The problem with return codes is that there is an underlying assumption
that the receiver will always catch and interpret that error code. This
may or may not be good thing, depending on how you architect your
application. If, on the other hand, you want to ensure that an error is
always handled, if not by the receiver then by the Forte, Exceptions are
the way to go. To extend this mechanism further, I would subclass
GenericException and created my own error code attribute on that
subclass. That way the receiver has the choice of interpreting the
exception based on that error code, and wrapping it in a
MessageDialog/window or do the usual 'errormgr.showerrors()'.
Exceptions seem a more flexible approach to me. That is, if you can live
with the fact that by using it, you're violating the 'exceptions for
behavioral anomalies' software engineering principle !
Best wishes.
Eric Pereira
Forte Consultant
----Original Message Follows----
From: "Kallambella, Ajith" <[email protected]>
To: "'Mark Sundsten'" <[email protected]>, [email protected]
Cc: [email protected]
Subject: RE: Raising Exceptions Vs returning error codes
Date: Wed, 30 Dec 1998 08:52:39 -0500
Reply-To: "Kallambella, Ajith" <[email protected]>
Mark,
Identifying conditions where you would rather use an exception
to an error_code ( and vice-versa ) normally depends on
your application design. Usually exceptions
are used to handle behavioral anomalies which are
not expected during the normal course of execution of
the program, and which would affect the continuity of
your algorithm if ignored. Examples would be a fatal
error, a semantically invalid( but syntactically-valid
token ) etc.
Error_codes and return status's can be used to handle
anticipated and recoverable errors. Example would
be presentation layer validations. In any normal
UI system, the user is expected to make errors and it
would be annoying to throw an exception( and to handle
it ), every time user enters wrong data. A well
modeled client layer should not only handle
data-validation errors , but should be smart enough
to encourage users to input correct or
"near-correct" data. Examples could be
making use of look-up windows etc. Interestingly,
Express uses exceptions to handle data-validations.
As you see, exceptions fit well into your processing
logic where severity of damage caused by an error
is more. Where as error_codes fit well into presentation
logic( and some not-so-critical processing logic ) where
errors are usually recoverable and normal path of
execution can be easily restored.
Hope this helps. I would be very interested to hear
what others have to say.
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Mark Sundsten [mailto:[email protected]]
Sent: Tuesday, December 29, 1998 2:10 PM
To: [email protected]
Cc: [email protected]
Subject: Raising Exceptions vs returning error codes
When dealing with error handling, I find myself struggling with the
choice
of
raising exceptions (and handling them) from the caller
vs returning an error code of somekind.
When would you want to use one over the other?
Should you always use exception handling?
Any discussion would be appreciated.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>