|
|
Posted by Jerry Stuckle on 07/18/07 14:21
Yarco wrote:
> On Jul 17, 8:16 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Yarco wrote:
>>> Well, friend. Yes, I'm doing PHP. But exception is a traditional
>>> machinism in programming languages. I'm very doubt about this.
>>> In procedure language, we return error code when we meet an error. So
>>> we need to design error code table and judge them in several
>>> statements. Finally they become boring.
>>> But how about use exception in OOP? Did we drop all "return error
>>> code" styles?
>>> If i want to fetch a webpage:
>>> <?php
>>> function fetchPage($url)
>>> {
>>> //...do something
>>> //if the net speed is very slow, cause we can't fetch the page
>>> throw new SlowNetSpeed("page can't be getted");
>>> //if the page is moved
>>> throw new NoPage("page does't exist");
>>> //...do something
>>> }
>>> // so what can i do, if i want the fetchPage procedure go on fetching
>>> when SlowNetSpeed Exception happen?
>>> // it stop when NoPage Exception happen?
>>> while (1)
>>> {
>>> try
>>> {
>>> $c = fetchPage('Some_Where');
>>> // do something
>>> break;
>>> }
>>> catch (SlowNetSpeed $e)
>>> {
>>> }
>>> catch(NoPage $e)
>>> {
>>> break;
>>> }
>>> }
>>> ?>
>>> It is very ugly if there exists more Exceptions and other procedure.
>>> Then i'm missing "return error code" style. But i know "return error
>>> code" is not a good method when we deal with error. And exception is
>>> also an ugly grammer when we want to keep code clean.
>> Exceptions originally were designed to handle unexpected conditions,
>> i.e. connection to a database failed. They really weren't designed to
>> replace normal error processing (i.e. userid/password mismatch).
>>
>> Normal errors are generally handled by the calling routine, but
>> unexpected conditions may be handled by the immediate caller - or
>> several layers higher. Exceptions give the ability to handle the
>> condition as high in the calling hierarchy as you need to, without
>> having to pass return codes from each routine in the which has been called.
>>
>> I still use them in this way, and it works well.
>>
> Erm...I'm thinking about the differences between error table and
> exception.
> It seems only one difference -- Exception can be caught in high level.
>
> Do you mean we need to use them togather?
>
(Top posting fixed)
I use both - which one depends on what I'm doing. If it's an error
which I expect to occur, i.e. "not found" on a database search,
incorrect (or missing) data in an entry field, etc., then I return an
error code. However, if it's an unexpected condition, i.e. unable to
connect to a database which should exist, then I return an exception.
P.S. Please don't top post. Thanks.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|