Re: Augmenting Types

Thomas 'PointedEars' Lahn wrote:

[...]


One should if an argument like yours is based on it.

My argument is not based on it at all. Why you can't see that is beyond
me. It's like you've got some wires crossed and I can't find the
short-circuit. I'm tired of trying.


And because we were talking about instantiating an ActiveX object.
How can you possibly know that this applies for the screenshot
without having seen the source code that lead to it? You keep
evading that simple question.
For the last time, as Kangax noted, that screen shot was not generated
by instantiating an ActiveX object. It was simply an illustration.
So if the screenshot was not of an error message generated by
instantiating an ActiveX object, how can you possibly know that there is
"no recovery from such an error", given that you have not even seen the
source code that lead to it (you only know that ActiveX objects are not
involved)?
You just can't seem to get your brain around this. I wasn't referring
to whatever error was used for the illustration, but the error that we
were discussing in the first place, which throws up the _same_ dialog
with a different message.

The screenshot is based on a completely different use-case then, which you
know nothing about. Yet you insist that you could tell

1. whether the exception was catchable;
2. whether try-catch was used or not;
3. how script code would be executed if one selected the "Yes" button.

That is illogical.

*Sigh* Except that I never asserted anything about the code used to
generate that screen shot.


If a try-catch was used, the exception would have been caught.
Iff the error was catchable, which we do not know.
We do know that.
No, we do not. We have not seen the source code, so all this is mere
assumption of yours.
Again, nobody cares about the whatever code was used to generate that
illustration.

No, *you* do not care about it, for sure.

Why would I? Kangax could shed light on it, but who cares?


It's irrelevant and how can you keep harping on it after all of this
discussion?

Because you referred to it ("such an error").

You just won't let that go, will you? I cleared that up 100 messages
back. :) Arguing endlessly about vague and misinterpreted semantics is
a complete waste of time.


As I said, it would be _ludicrous_ if MS did not allow you to catch
such exceptions
And I do not concur.
It wouldn't be ludicrous? How, pray tell, would you instantiate
ActiveX objects if there was no way to account for the fact that they
may not instantiate?

Wrong question. Whether it would be ludicrous or not depends on the
context, i.e. on the use-case and on the person making that assessment.

The use case in question has never been in doubt (except perhaps to you).


(given the fact that the component may not be available).
Non sequitur.*
I really dislike this sort of endless arguing about nothing.

Then I suggest you do not make fallacious arguments, and be clearer (less
pictorial, perhaps) in our wording. I am only trying my best here to get
some clarity into this "muddied water" of yours, and you are not making it
easy.

Nobody's paying attention at this point. I promise. :)


if no try-catch was used (as with jQuery), the exception will not
be caught. That goes without saying. What does not go without
saying is that an error message can be displayed even though the
exception was attempted to be caught with try-catch, a fact that
you still appear to miss.
I miss no such thing. In the context we are discussing (ActiveX
object instantiation), it does not apply.
Why the inappropriate example then?
What inappropriate example? The screen shot? As Kangax noted, it was
for illustration purposes only and the error message would be
different if it were actually generated by a failed ActiveX
instantiation. Sheesh.

The error message would have been different, the underlying source code
would have been different, and the outcome of selecting "Yes" might also
have been different. Exactly my point.

I'm using a newsreader now. I can plonk you for real. Fair warning. :)


I was pointing out that it was not (i.e. it would not
magically recover on clicking "No"). Clear now?
No, for there is a "Yes" button which facilitates the recovery.
The "Yes" button doesn't recover anything. The execution has
_dropped dead_ at that point (i.e. if you can see the exception
dialog, it's too late). ;)
Too late for what exactly? Is this all mere assumption?
Too late for the script in question to go on about its merry way.
Is there any proof for your assumption?
Proof that uncaught exceptions derail executions without recourse?

Yes (IIUC).

That's like asking to prove that 1 + 1 = 2. What's the point?


Other scripts can try to get by after that,
Define: other scripts
"Other scripts on the page" as mentioned on the dialog in question.
This really is a ludicrous discussion at this point.
That is a recursive definition, so I have to concur with your
assessment.
I have no idea what you are talking about at this point.

You define "other scripts" as "other scripts on the page" which is not
particularly helpful for knowing what "other scripts" is supposed to be.

This is going nowhere.


but it is unlikely they will succeed
How so? They could use completely different references.
Once one script blows up, all bets are off. The document may not even
be usable at that point (let alone script-able in any sort of
predictable manner). But sure, some scripts could succeed. Seems
like I already said that.
Your probability argument is fallacious.
I don't think so.

You do not know anything of the other code, so you are not in a position to
assess the probability of failure.

Whatever.


(and I can't believe I'm writing all of this again).
You better believe it. As for "again": Message-ID for some *facts*?
Parse error (and I can't believe I said _that_).
You have stated that this was not the first time you said it. So there
must be a Message-ID of a posting in which you said it before,
containing facts to support your assumption.

Well?

Well what? You snipped whatever it was I was talking about.


Why are you muddying the waters like this?
On the contrary, I seek clarity on what has already been muddied by
you.
Well, it isn't working.
Unfortunately.
Can we agree to stop trying to clarify whatever it is you think needs
clarifying then?

I am afraid we cannot.


Dammit. :( But seriously, this will be my last word on this "topic".
I just wanted to test the TB setup. Thanks!
.

Relevant Pages

  • Re: Form Security
    ... After all this, if no error message has been generated, the form contents are emailed to me. ... I'm no Linux guru, so I don't know what someone could do to cause problems with this script, other than spam me. ... What he's proposing is false security - which is worse than no security ...
    (comp.lang.php)
  • RE: Cannot Edit Logion Scripts
    ... remove the script that you would like to edit. ... Please capture a screenshot of the error message received on the client ... Microsoft Online Newsgroup Support ... This newsgroup only focuses on SBS technical issues. ...
    (microsoft.public.windows.server.sbs)
  • Re: Error in script of Internet Explorer
    ... Uncheck the box to Display a notification about every script error. ... Windows Script 5.6 for Windows 2000 and XP ... Error Message When You Browse the Web: An Error Has Occurred in the Script ... Please reply to the newsgroup so others may benefit. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: Sound file
    ... There shouldn't be any problems in the limited user accounts. ... The only other problem just about has to be with the attaching of the .wav ... > Common script errors messages can be eliminated by Clicking: ... >> click on the html file we get an error message and the wav file does ...
    (microsoft.public.windowsxp.accessibility)
  • Re: Monitor GUI
    ... I currently have a simple little Perl script whose job is to listen on ... a TCL window. ... red when we've gotten an error message. ... GUI never gets created. ...
    (comp.lang.perl.tk)