Re: Exception : an ugly grammer in programming

Yarco wrote:
On Jul 17, 8:16 pm, Jerry Stuckle <jstuck...@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: Exception : an ugly grammer in programming
    ... machinism in programming languages. ... we return error code when we meet an error. ... But how about use exception in OOP? ... perform that task is an exception, but a slow connection is not. ...
    (comp.lang.php)
  • Re: Structured exception information
    ... Doesn't feel as type-safe as advertised. ... What, _exactly_, will the handler do with the separate bits? ... Looking up the localized error message in the dictionary based on the *type-safe* error code that it got from the exception object, ... I'm looking forward to see a convincing solution for error code and the dictionary. ...
    (comp.lang.ada)
  • Re: [PHP] Re: MySQL exceptions
    ... I don't think MySQL or even mysqli have any kind of exception throwing ... echo "Impossible connect to server."; ... completely before trying to use a dead connection. ... error code number would be encapsulated as an ...
    (php.general)
  • Exception : an ugly grammer in programming
    ... Yes, I'm doing PHP. ... machinism in programming languages. ... we return error code when we meet an error. ... But how about use exception in OOP? ...
    (comp.lang.php)
  • Re: Structured exception information
    ... A real example is a HTTP component that reports error code with value 404 and the GUI leyer that looks up the dictionary of messages for currently selected language to resolve it to whatever is appropriate for display. ... You can argue that return code instead of exception might do the job and that's true - but then we are back to the discussion of return codes vs. exceptions, which is a paradigm issue - which should be independent on the technical abilities of each solution. ...
    (comp.lang.ada)