sintax for try and except istruction

Discussion in 'Javascript' started by SAN CAZIANO, Oct 9, 2004.

  1. SAN CAZIANO

    SAN CAZIANO Guest

    is there an istruction like the
    try .....
    except.....
     
    SAN CAZIANO, Oct 9, 2004
    #1
    1. Advertising

  2. SAN CAZIANO

    VK Guest

    > try .....
    > except.....


    You ment the clause:
    try {} catch (e) {} finally{}

    Yes, it has been relatively recently added to both JavaScript and JScript.
    Never seen it in use yet though in actual scripts. Either no much use, or
    some implementation errors, or I don't know.
    Would be great to get some feed-back from who ever used it.
     
    VK, Oct 9, 2004
    #2
    1. Advertising

  3. On Sat, 09 Oct 2004 10:44:35 GMT, SAN CAZIANO <> wrote:

    > is there an istruction like the
    > try .....
    > except.....


    var e;

    try {

    // Execute exception-causing code here

    } catch(e) {

    // e represents the exception thrown

    } finally {

    // Code always executed, whether an exception was thrown or not

    }

    A try statement doesn't require both of the catch and finally clauses, but
    at least one of them must be included.

    This is a fairly recent addition to the language. Browsers like NN4 will
    error when encountering these keywords as they were reserved during that
    time. IE5, Netscape 6 and Mozilla will support try..catch. I don't know
    when Opera began support.

    Are you certain you need to use these statements?

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
     
    Michael Winter, Oct 9, 2004
    #3
  4. One reason why it is used and in fact I use it for this reason.

    When your page loads you cannot refer to an element's id until the element has actually been created. Now
    consider you have made a page that is actually a template. The page dynamically loads an image. If the image is
    large the <div id="oLImage...> loads but if the image is small <div id="oSImage ...> loads. You don't know
    which image is going to be requested and therefore which div will be made. One or the other but not both will
    be made. Here's the solution:

    try{
    // do something with element id='oLImage'
    }
    catch{
    //do something with element id='oSImage'
    }

    No script errors on the page but in fact an error does occur when <div id='oSImage'....> (the image is
    small) results which goes to the catch().

    --
    George Hester
    __________________________________
    "VK" <> wrote in message news:4167ce96$0$160$...
    > > try .....
    > > except.....

    >
    > You ment the clause:
    > try {} catch (e) {} finally{}
    >
    > Yes, it has been relatively recently added to both JavaScript and JScript.
    > Never seen it in use yet though in actual scripts. Either no much use, or
    > some implementation errors, or I don't know.
    > Would be great to get some feed-back from who ever used it.
    >
    >
     
    George Hester, Oct 9, 2004
    #4
  5. I'm sorry it should be:

    try{
    // do something with element id='oLImage'
    }
    catch(e){
    //do something with element id='oSImage'
    }

    You can use the e to get the actual error message if you want:

    try{
    // do something with element id='oLImage'
    }
    catch(e){
    var errMsg = 'The error was:\n\n';
    errMsg += 'Error number: '+(e.number & 0xFFFF);
    errMsg += '\n'+e.description;
    //do something with element id='oSImage'
    // alert(errMsg);
    }

    --
    George Hester
    __________________________________
    "George Hester" <> wrote in message news:32S9d.144679$...
    One reason why it is used and in fact I use it for this reason.

    When your page loads you cannot refer to an element's id until the element has actually been created. Now
    consider you have made a page that is actually a template. The page dynamically loads an image. If the image is
    large the <div id="oLImage...> loads but if the image is small <div id="oSImage ...> loads. You don't know
    which image is going to be requested and therefore which div will be made. One or the other but not both will
    be made. Here's the solution:

    try{
    // do something with element id='oLImage'
    }
    catch{
    //do something with element id='oSImage'
    }

    No script errors on the page but in fact an error does occur when <div id='oSImage'....> (the image is
    small) results which goes to the catch().

    --
    George Hester
    __________________________________
    "VK" <> wrote in message news:4167ce96$0$160$...
    > > try .....
    > > except.....

    >
    > You ment the clause:
    > try {} catch (e) {} finally{}
    >
    > Yes, it has been relatively recently added to both JavaScript and JScript.
    > Never seen it in use yet though in actual scripts. Either no much use, or
    > some implementation errors, or I don't know.
    > Would be great to get some feed-back from who ever used it.
    >
    >
     
    George Hester, Oct 9, 2004
    #5
  6. On Sat, 09 Oct 2004 13:51:59 GMT, George Hester <>
    wrote:

    [snip]

    > The page dynamically loads an image. If the image is large the <div
    > id="oLImage...> loads but if the image is small
    > <div id="oSImage ...> loads. You don't know which image is going to be
    > requested and therefore which div will be made.


    [snip]

    > No script errors on the page but in fact an error does occur when <div
    > id='oSImage'....> (the image is small) results which goes to the
    > catch().


    Assuming I understand you correctly, that isn't a valid reason to use
    try..catch. Assuming you can't generate code that is relevant to the
    generated mark-up, test. If the element doesn't exist, you won't get a
    valid object reference. You simply need to test for that and act
    accordingly. But as I said, generating the correct script for the current
    mark-up is surely the sensible thing to do.

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
     
    Michael Winter, Oct 9, 2004
    #6
  7. "Michael Winter" <> wrote in message news:eek:psflw0iiix13kvk@atlantis...
    > On Sat, 09 Oct 2004 13:51:59 GMT, George Hester <>
    > wrote:
    >
    > [snip]
    >
    > > The page dynamically loads an image. If the image is large the <div
    > > id="oLImage...> loads but if the image is small
    > > <div id="oSImage ...> loads. You don't know which image is going to be
    > > requested and therefore which div will be made.

    >
    > [snip]
    >
    > > No script errors on the page but in fact an error does occur when <div
    > > id='oSImage'....> (the image is small) results which goes to the
    > > catch().

    >
    > Assuming I understand you correctly, that isn't a valid reason to use
    > try..catch. Assuming you can't generate code that is relevant to the
    > generated mark-up, test. If the element doesn't exist, you won't get a
    > valid object reference. You simply need to test for that and act


    the test is try() the act accordingly is catch(e){}

    > accordingly. But as I said, generating the correct script for the current
    > mark-up is surely the sensible thing to do.
    >
    > Mike


    >
    > --
    > Michael Winter
    > Replace ".invalid" with ".uk" to reply by e-mail.


    What's the problem with that?

    George Hester
    __________________________________
     
    George Hester, Oct 9, 2004
    #7
  8. On Sat, 09 Oct 2004 14:50:32 GMT, George Hester <>
    wrote:

    [snip]

    >> Assuming I understand you correctly, that isn't a valid reason to use
    >> try..catch. Assuming you can't generate code that is relevant to the
    >> generated mark-up, test. If the element doesn't exist, you won't get a
    >> valid object reference. You simply need to test for that and act
    >> [accordingly.]

    >
    > the test is try() the act accordingly is catch(e){}


    [snip]

    > What's the problem with that?


    It's unnecessary?

    If you have an object reference,

    if(objRef) {

    will check if it's non-null. If at the time of that test, objRef
    references one DIV that doesn't exist, the reference will be null and the
    expression will evaluate as false.

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
     
    Michael Winter, Oct 9, 2004
    #8
  9. "Michael Winter" <> wrote in message news:eek:psfl01bhnx13kvk@atlantis...
    > On Sat, 09 Oct 2004 14:50:32 GMT, George Hester <>
    > wrote:
    >
    > [snip]
    >
    > >> Assuming I understand you correctly, that isn't a valid reason to use
    > >> try..catch. Assuming you can't generate code that is relevant to the
    > >> generated mark-up, test. If the element doesn't exist, you won't get a
    > >> valid object reference. You simply need to test for that and act
    > >> [accordingly.]

    > >
    > > the test is try() the act accordingly is catch(e){}

    >
    > [snip]
    >
    > > What's the problem with that?

    >
    > It's unnecessary?
    >
    > If you have an object reference,
    >
    > if(objRef) {
    >
    > will check if it's non-null. If at the time of that test, objRef
    > references one DIV that doesn't exist, the reference will be null and the
    > expression will evaluate as false.
    >
    > Mike
    >
    > --
    > Michael Winter
    > Replace ".invalid" with ".uk" to reply by e-mail.


    six of one 1/2 dozen of the other

    I never said it was necessary just sufficient for browsers which support it.

    George Hester
    __________________________________
     
    George Hester, Oct 9, 2004
    #9
  10. George Hester wrote:
    > Michael Winter wrote:
    >> George Hester wrote:

    <snip>
    >>> No script errors on the page but in fact an error does occur
    >>> when <div id='oSImage'....> (the image is small) results
    >>> which goes to the catch().

    >>
    >> Assuming I understand you correctly, that isn't a valid reason
    >> to use try..catch. Assuming you can't generate code that is
    >> relevant to the generated mark-up, test. If the element doesn't
    >> exist, you won't get a valid object reference. You simply
    >> need to test for that and act

    >
    > the test is try() the act accordingly is catch(e){}

    <snip>

    try-catch-finally is designed to handle exceptions; exceptions being
    conditions outside of the ability of normal code to detect and control.
    Their use in place of normal program flow control logic is
    inappropriate, relatively inefficient (lots of overheads in scope chain
    modification), incorrect, and should be broadly categorised as a hack.

    It doesn't surprise me that you use try-catch for flow control, but as
    usual you should not inflict your nonsense on others.

    Richard.
     
    Richard Cornford, Oct 9, 2004
    #10
  11. "Richard Cornford" <> wrote in message news:ck998a$ol6$1$...
    > George Hester wrote:
    > > Michael Winter wrote:
    > >> George Hester wrote:

    > <snip>
    > >>> No script errors on the page but in fact an error does occur
    > >>> when <div id='oSImage'....> (the image is small) results
    > >>> which goes to the catch().
    > >>
    > >> Assuming I understand you correctly, that isn't a valid reason
    > >> to use try..catch. Assuming you can't generate code that is
    > >> relevant to the generated mark-up, test. If the element doesn't
    > >> exist, you won't get a valid object reference. You simply
    > >> need to test for that and act

    > >
    > > the test is try() the act accordingly is catch(e){}

    > <snip>
    >
    > try-catch-finally is designed to handle exceptions; exceptions being
    > conditions outside of the ability of normal code to detect and control.
    > Their use in place of normal program flow control logic is
    > inappropriate, relatively inefficient (lots of overheads in scope chain
    > modification), incorrect, and should be broadly categorised as a hack.
    >
    > It doesn't surprise me that you use try-catch for flow control, but as
    > usual you should not inflict your nonsense on others.
    >
    > Richard.
    >
    >


    Why you Richard are determined to always patronize me whenever you find my posts.
    Why don't you just block my posts? Pleasre put me on your ban list then I won't have to read your
    crap. You don't like my crap so ban me. PLEASE!!!

    As for your comment about the try catch well taken and is exactly why I used it. How you saw
    it done is yes unnecessary but so goddamn what.

    --
    George Hester
    __________________________________
     
    George Hester, Oct 9, 2004
    #11
  12. George Hester wrote:
    > Richard Cornford wrote:
    >> George Hester wrote:

    <snip>
    >>> the test is try() the act accordingly is catch(e){}

    >> <snip>
    >> try-catch-finally is designed to handle exceptions; exceptions
    >> being conditions outside of the ability of normal code to
    >> detect and control. Their use in place of normal program flow
    >> control logic is inappropriate, relatively inefficient (lots
    >> of overheads in scope chain modification), incorrect, and
    >> should be broadly categorised as a hack.
    >>
    >> It doesn't surprise me that you use try-catch for flow control,
    >> but as usual you should not inflict your nonsense on others.

    >
    > Why you Richard are determined to always patronize me whenever
    > you find my posts.


    I am determined that the universally (and often uniquely) bad advice you
    give out should not exist in a public arena without an appropriate
    indication of its true status.

    > Why don't you just block my posts? Pleasre put me on your
    > ban list then I won't have to read your crap.


    If you don't want to read my "crap" you can killfile me. You are in
    complete control of your ability to do that, and I have no intention of
    doing what you suggest. To date I have never killfiled anyone (I have
    come close a couple of times).

    > You don't like my crap so ban me. PLEASE!!!


    If I could be confident that you would not attempt to inflict your crap
    on innocent third parities then killfiling you might be the simplest
    option. But as you insist on posting responses to questions it will
    remain necessary to be able to advise the recipients of your "answers"
    that advice originating with George Hester is best regarded as
    intrinsically wrong and that doing anything else would probably be a
    better alternative.

    > As for your comment about the try catch well taken and
    > is exactly why I used it.


    Yes, your clearly use try-catch for program flow control.

    > How you saw it done is yes unnecessary but so goddamn what.


    It is a manifestation of the difference between programming and what you
    do.

    Richard.
     
    Richard Cornford, Oct 9, 2004
    #12
  13. SAN CAZIANO

    Jeff North Guest

    On Sat, 09 Oct 2004 10:44:35 GMT, in comp.lang.javascript "SAN
    CAZIANO" <> wrote:

    >| is there an istruction like the
    >| try .....
    >| except.....


    Other people have pointed out the syntax of try/catch.
    How are you planning to use this, client-side or server-side?

    While I believe there is little use with client-side code there is
    good reasons to have this server-side (database updates, file
    read/write, file transfers etc).

    ---------------------------------------------------------------
    : Remove your pants to reply
    ---------------------------------------------------------------
     
    Jeff North, Oct 10, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Salerno
    Replies:
    20
    Views:
    889
    John Salerno
    Aug 11, 2006
  2. Fabio Z Tessitore

    who is simpler? try/except/else or try/except

    Fabio Z Tessitore, Aug 12, 2007, in forum: Python
    Replies:
    5
    Views:
    400
  3. David House

    try -> except -> else -> except?

    David House, Jul 6, 2009, in forum: Python
    Replies:
    2
    Views:
    367
    Bruno Desthuilliers
    Jul 6, 2009
  4. MRAB
    Replies:
    4
    Views:
    328
  5. Peng Yu
    Replies:
    1
    Views:
    567
    Steven D'Aprano
    Nov 18, 2009
Loading...

Share This Page