sintax for try and except istruction

[SAN CAZIANO]

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

 

[VK]

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.

 

[Michael Winter]

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

 

[George Hester]

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]

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
__________________________________
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().

 

[Michael Winter]

[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

 

[George Hester]

[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

What's the problem with that?

George Hester
__________________________________

 

[Michael Winter]

[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

 

[George Hester]

[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

six of one 1/2 dozen of the other

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

George Hester
__________________________________

 

[Richard Cornford]

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.

 

[George Hester]

<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.

 

[Richard Cornford]

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.

 

[Jeff North]

| 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).