|
|
| Do you know where your variables are? | |
| PerlMonks |
Re: Re: Best Practices for Exception Handlingby IlyaM (Parson) |
| on Feb 03, 2003 at 22:26 UTC ( #232395=note: print w/replies, xml ) | Need Help?? |
|
Do you agree that the logic responsible for asking users for a better
input belongs to the user interface part and it is not a part of the
business logic? I.e. business logic layer have to callback user
interface part when it tries to do the error recovery. So you still have
to pass control to the callee to do the error recovery that business logic part
cannot do on its own as if you were using exception or return codes
style of error handling. To me it looks that the error recovery mechanism is essantially the
same in both cases.
The only difference is added complexity of callback approach. Let's plot a couple of diagrams. Traditional approach (exceptions or return codes) for case when the business logic part bails with error: If at the last point the user interface part can handle the error it can either ask the business logic part to redo the action or if this error is unrecoverable print diagnostic error or do something else. Now callback approach:
This diagram clearly show two problems:
--
In Section
Seekers of Perl Wisdom
|
|
||||||||||||||||||||||||