Suppressing err msg globally

[Don Li]

Hi,

A web app server package that I'm using includes a bunch of open
source UI components (heavy with javascripts). Inevitably it has
bugs, e.g. "undefined" is null or not an object.

This naturally erodes confidence for novice web users for the app in
question.

The techniques that I found and tried after research for suppressing
javascript err mgs either completely stop all the js running or
ineffective. Got an idea?

Thanks.

 

[Richard Cornford]

A web app server package that I'm using includes a bunch
of open source UI components (heavy with javascripts).
Inevitably it has bugs, e.g. "undefined" is null or not
an object.

This naturally erodes confidence for novice web users for
the app in question.

The implication being, I suppose, that experienced web users would have
no confidence in the application to start with and so a series of script
error messages could no erode their confidence.

The techniques that I found and tried after research
for suppressing javascript err mgs

That would easily be the very worst thing you could ever do.

either completely
stop all the js running

That would do it.

or ineffective.

You are obviously looking in the wrong place for advice as suppressing
all javascript errors is trivial, but an incredibly bad idea.

Got an idea?

Debug and correct the code you have or use better code to start with.

Richard.

 

[Don Li]

The implication being, I suppose, that experienced web users would have
no confidence in the application to start with and so a series of script
error messages could no erode their confidence.


That would easily be the very worst thing you could ever do.


That would do it.


You are obviously looking in the wrong place for advice as suppressing
all javascript errors is trivial, but an incredibly bad idea.


Debug and correct the code you have or use better code to start with.

Richard.

Ok, it looks like I did not make my case clear. First of all, I'm not
shooting for 100%, 99% or even 97% "completeness"/"correctness" for
the app, and the errors are really HARMLESS (they did not prevent
designed functions from running/executing). Hence, experienced web
users would know the error message in the status bar does not mean
anything to them other than annoyance.

 

[Jeremy J Starcher]

[snipped]

That would easily be the very worst thing you could ever do.



Debug and correct the code you have or use better code to start with.

Richard.

Ok, it looks like I did not make my case clear. First of all, I'm not
shooting for 100%, 99% or even 97% "completeness"/"correctness" for the
app, and the errors are really HARMLESS (they did not prevent designed
functions from running/executing). Hence, experienced web users would
know the error message in the status bar does not mean anything to them
other than annoyance.

Even if that is true *now*, you can't count on it being true in the
future.

IMHO, "experienced web users" don't have any idea what Javascript nor
respond rationally to error messages. They either don't notice anything,
or they notice everything that is out of the norm.

Hiding error messages leads to further problems down the road, should any
real errors begin to occur. You are trying to open Pandora's box of
debugging.

Thirdly, while most UAs (User Agents/browsers) will continue running in
case of an error, there is no requirement that they do so.

 

[Don Li]

Don Li wrote:
A web app server package that I'm using includes a bunch of open
source UI components (heavy with javascripts). Inevitably it has
bugs, e.g. "undefined" is null or not an object.

[snipped]

The techniques that I found and tried after research for suppressing
javascript err mgs
That would easily be the very worst thing you could ever do.
Got an idea?
Debug and correct the code you have or use better code to start with.
Richard.

Ok, it looks like I did not make my case clear.  First of all, I'm not
shooting for 100%, 99% or even 97% "completeness"/"correctness" for the
app, and the errors are really HARMLESS (they did not prevent designed
functions from running/executing).  Hence, experienced web users would
know the error message in the status bar does not mean anything to them
other than annoyance.

Even if that is true *now*, you can't count on it being true in the
future.

IMHO, "experienced web users" don't have any idea what Javascript nor
respond rationally to error messages.  They either don't notice anything,
or they notice everything that is out of the norm.

Hiding error messages leads to further problems down the road, should any
real errors begin to occur.  You are trying to open Pandora's box of
debugging.

Thirdly, while most UAs (User Agents/browsers) will continue running in
case of an error, there is no requirement that they do so.- Hide quoted text -

- Show quoted text -

"Hiding error messages leads to further problems down the road, should
any
real errors begin to occur."
That's why we have Dev vs Production, on the Dev, err msgs won't be
suppressed.

 

[Richard Cornford]

On Apr 1, 5:20 pm, Jeremy J Starcher wrote:

"Hiding error messages leads to further problems down the road,
should any real errors begin to occur."

That's why we have Dev vs Production, on the Dev, err msgs won't
be suppressed.

If you don't have people who either already know how to suppress all
error messages (and why it would be a suicidal bad idea) or how to
identify cause and effect relationships that result in error messages
and so how to fix them then you don't have 'development' at all. Just
some sort of uncontrolled code aggregation process. Any confidence in
the outcome is already unfounded.

Richard.

 

[rf]

"Hiding error messages leads to further problems down the road, should
any
real errors begin to occur."

That's why we have Dev vs Production, on the Dev, err msgs won't be
suppressed.

No. You have this wrong [1].

You have a development environment so you can find and correct the errors.
All of them.

When a development environment is free of errors and, hopefully, works
correctly, you may promote it to the production environment.

If you have *any errors at all* in a specific development environment then
that canditate is not eligable for promotion to production status. There
shall be NO [known] errors in the production environment.

At least that's what they taught us in Programming 101 back in nineteen
seventy three. I would hope it still applies.

However I see that you are a google groper. All bets are off then

[1] You *may* in your development environment allow all sorts of debugging
stuff to happen, alerts and what not, that will be suppressed in the
production environment. But not so for errors.

 

[Don Li]

"Hiding error messages leads to further problems down the road, should
any
real errors begin to occur."
That's why we have Dev vs Production, on the Dev, err msgs won't be
suppressed.

No. You have this wrong [1].

You have a development environment so you can find and correct the errors.
All of them.

When a development environment is free of errors and, hopefully, works
correctly, you may promote it to the production environment.

If you have *any errors at all* in a specific development environment then
that canditate is not eligable for promotion to production status. There
shall be NO [known] errors in the production environment.

At least that's what they taught us in Programming 101 back in nineteen
seventy three. I would hope it still applies.

However I see that you are a google groper. All bets are off then

[1] You *may* in your development environment allow all sorts of debugging
stuff to happen, alerts and what not, that will be suppressed in the
production environment. But not so for errors.

It appears that we are not communicating. My point is, all the
functions have been tested by multiple beta testers to be at least 97%
reliable. Hence, the harmless error messages generated by open source
javascripts can be safely ignored and in order not to discourage
novice users it might not be a bad idea to suppress such err msgs...

As for UA, you don't need to lecutre me, I knew what UA is, 3 months
into web development (back over 10 years ago... have not done
javascripting for the last 2.5 years, got rusty on that, am warming up
on that now...)

What is most despicable is that, my work is constantly sabotaged by
evil doers (no, I can't be all, expert in software security, expert
in... expert in...), of course not talking about you.

 

[Thomas 'PointedEars' Lahn]

[Fixed quotation levels]

Hiding error messages leads to further problems down the road, should
any real errors begin to occur."
That's why we have Dev vs Production, on the Dev, err msgs won't be
suppressed.

No. You have this wrong [1].

You have a development environment so you can find and correct the errors.
All of them.

When a development environment is free of errors and, hopefully, works
correctly, you may promote it to the production environment.

If you have *any errors at all* in a specific development environment then
that canditate is not eligable for promotion to production status. There
shall be NO [known] errors in the production environment.

At least that's what they taught us in Programming 101 back in nineteen
seventy three. I would hope it still applies.

However I see that you are a google groper. All bets are off then

[1] You *may* in your development environment allow all sorts of debugging
stuff to happen, alerts and what not, that will be suppressed in the
production environment. But not so for errors.
[...]

It appears that we are not communicating.

That impression is surprisingly precise, for you have not been listening to
what was said.

My point is, all the functions have been tested by multiple beta testers to be at least 97%
reliable.

Even if we assumed that these figures could ever be correct, they were still
irrelevant. Bad code does not become good code when you hide the errors it
creates.

Hence, the harmless error messages generated by open source
javascripts can be safely ignored

If error messages have been observed, and you could do something about them,
it is simply stupid to ignore them. Avoiding errors before they occur is
part of good software engineering.

and in order not to discourage novice users

Your notion of novice users in this context is mistaken, as they might as
well not notice the errors (using IE with script error display disabled by
default), although there is no guarantee for that (e.g. there is still the
error icon bottom left in the statusbar there).

It is more likely that experienced users, particularly other Web developers,
will recognize these errors for what they are, call you an incompetent
half-wit never to be considered for employment in the first place, and be
right about that. I find it hard to believe that you really want that.

it might not be a bad idea to suppress such err msgs...

So far it is an incredibly bad idea.

As for UA, you don't need to lecutre me, I knew what UA is, 3 months
into web development (back over 10 years ago... have not done
javascripting for the last 2.5 years, got rusty on that, am warming up
on that now...)
ROTFL

What is most despicable is that, my work is constantly sabotaged by
evil doers (no, I can't be all, expert in software security, expert
in... expert in...), of course not talking about you.

Cry harder!


PointedEars

 

[dhtml]

No. You have this wrong [1].

You have a development environment so you can find and correct the errors.
All of them.

When a development environment is free of errors and, hopefully, works
correctly, you may promote it to the production environment.

If you have *any errors at all* in a specific development environment then
that canditate is not eligable for promotion to production status. There
shall be NO [known] errors in the production environment.

At least that's what they taught us in Programming 101 back in nineteen
seventy three. I would hope it still applies.

However I see that you are a google groper. All bets are off then

[1] You *may* in your development environment allow all sorts of debugging
stuff to happen, alerts and what not, that will be suppressed in the
production environment. But not so for errors.

It appears that we are not communicating.  My point is, all the
functions have been tested by multiple beta testers to be at least 97%
reliable.  Hence, the harmless error messages generated by open source
javascripts can be safely ignored and in order not to discourage
novice users it might not be a bad idea to suppress such err msgs...

You need to do lower level testing. If the open source javascript
throws an error, that can be directly reported to the authors.

The stuff that the users are testing sounds like stories/acceptance
testing and can mostly be automated, too. Regardless, this
"functional" testing doesn't test the javascript functions.

The lower level functions can, for example, have a problem. Maybe
function X doesn't handle nulls. Then, 5 layers of abstraction later,
on the screen, the user gets an error. The real problem can't be found
unless you figure out what is actually happening. That isn't going to
happen with acceptance/story/functional testing.

 

[VK]

Hi,

A web app server package that I'm using includes a bunch of open
source UI components (heavy with javascripts). Inevitably it has
bugs, e.g. "undefined" is null or not an object.

This naturally erodes confidence for novice web users for the app in
question.

The techniques that I found and tried after research for suppressing
javascript err mgs either completely stop all the js running or
ineffective. Got an idea?

window.onerror = function(){return true;};
or (equivalent):
<body onerror="return true;">

That prevents from showing any error messages, but on the first
runtime error occurred the script execution will stop globally, as you
already properly noticed. The only workaround exists for Gecko
browsers implementing multi-threating in Javascript (it was necessary
as the whole top and middle layer of Gecko are written in Javascript).
For Gecko the execution and clean up happen only for the current
execution context, so on unhandled runtime error one may escape to a
parallel context over timeout:

window.onerror = function(){
window.setTimeout('resumeNext()',1);
return true;
}

That is a very risky way to handle anything and I would strongly
oppose to such coding moreover it's Gecko-only. Still I had to
mention.

Javascript doesn't have On Error Resume Next and similar constructs.
This way the only mean to prevent errors bubbling yet keep the script
executing is to try to wrap it in whole into try-catch block. Uhmm...
Do you really want to try that?

So no, there is not anything close to what you are asking about.

 

[Don Li]

[Fixed quotation levels]

Hiding error messages leads to further problems down the road, should
any real errors begin to occur."
That's why we have Dev vs Production, on the Dev, err msgs won't be
suppressed.
No. You have this wrong [1].
You have a development environment so you can find and correct the errors.
All of them.
When a development environment is free of errors and, hopefully, works
correctly, you may promote it to the production environment.
If you have *any errors at all* in a specific development environment then
that canditate is not eligable for promotion to production status. There
shall be NO [known] errors in the production environment.
At least that's what they taught us in Programming 101 back in nineteen
seventy three. I would hope it still applies.
However I see that you are a google groper. All bets are off then
[1] You *may* in your development environment allow all sorts of debugging
stuff to happen, alerts and what not, that will be suppressed in the
production environment. But not so for errors.
[...]

It appears that we are not communicating.

That impression is surprisingly precise, for you have not been listening to
what was said.

My point is, all the functions have been tested by multiple beta testersto be at least 97%
reliable.

Even if we assumed that these figures could ever be correct, they were still
irrelevant.  Bad code does not become good code when you hide the errorsit
creates.

Hence, the harmless error messages generated by open source
javascripts can be safely ignored

If error messages have been observed, and you could do something about them,
it is simply stupid to ignore them.  Avoiding errors before they occur is
part of good software engineering.

and in order not to discourage novice users

Your notion of novice users in this context is mistaken, as they might as
well not notice the errors (using IE with script error display disabled by
default), although there is no guarantee for that (e.g. there is still the
error icon bottom left in the statusbar there).

It is more likely that experienced users, particularly other Web developers,
will recognize these errors for what they are, call you an incompetent
half-wit never to be considered for employment in the first place, and be
right about that.  I find it hard to believe that you really want that.

it might not be a bad idea to suppress such err msgs...

So far it is an incredibly bad idea.

As for UA, you don't need to lecutre me, I knew what UA is, 3 months
into web development (back over 10 years ago... have not done
javascripting for the last 2.5 years, got rusty on that, am warming up
on that now...)
ROTFL

What is most despicable is that, my work is constantly sabotaged by
evil doers (no, I can't be all, expert in software security, expert
in... expert in...), of course not talking about you.

Cry harder!

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm>- Hide quoted text -

- Show quoted text -

You're ABSOLUTELY despicable! Just have littel respect for yourself
of NOT RESPONDING to my post. We all have the freedom of "doing or
not doing"! Enough of your your twisted CRAP!

 

[Don Li]

"Hiding error messages leads to further problems down the road, should
any
real errors begin to occur."
That's why we have Dev vs Production, on the Dev, err msgs won't be
suppressed.
No. You have this wrong [1].
You have a development environment so you can find and correct the errors.
All of them.
When a development environment is free of errors and, hopefully, works
correctly, you may promote it to the production environment.
If you have *any errors at all* in a specific development environment then
that canditate is not eligable for promotion to production status. There
shall be NO [known] errors in the production environment.
At least that's what they taught us in Programming 101 back in nineteen
seventy three. I would hope it still applies.
However I see that you are a google groper. All bets are off then
[1] You *may* in your development environment allow all sorts of debugging
stuff to happen, alerts and what not, that will be suppressed in the
production environment. But not so for errors.

It appears that we are not communicating.  My point is, all the
functions have been tested by multiple beta testers to be at least 97%
reliable.  Hence, the harmless error messages generated by open source
javascripts can be safely ignored and in order not to discourage
novice users it might not be a bad idea to suppress such err msgs...

You need to do lower level testing. If the open source javascript
throws an error, that can be directly reported to the authors.

The stuff that the users are testing sounds like stories/acceptance
testing and can mostly be automated, too. Regardless, this
"functional" testing doesn't test the javascript functions.

The lower level functions can, for example, have a problem. Maybe
function X doesn't handle nulls. Then, 5 layers of abstraction later,
on the screen, the user gets an error. The real problem can't be found
unless you figure out what is actually happening. That isn't going to
happen with acceptance/story/functional testing.- Hide quoted text -

- Show quoted text -

Thanks.

 

[Don Li]

window.onerror = function(){return true;};
 or (equivalent):
<body onerror="return true;">

That prevents from showing any error messages, but on the first
runtime error occurred the script execution will stop globally, as you
already properly noticed. The only workaround exists for Gecko
browsers implementing multi-threating in Javascript (it was necessary
as the whole top and middle layer of Gecko are written in Javascript).
For Gecko the execution and clean up happen only for the current
execution context, so on unhandled runtime error one may escape to a
parallel context over timeout:

window.onerror = function(){
 window.setTimeout('resumeNext()',1);
 return true;

}

That is a very risky way to handle anything and I would strongly
oppose to such coding moreover it's Gecko-only. Still I had to
mention.

Javascript doesn't have On Error Resume Next and similar constructs.
This way the only mean to prevent errors bubbling yet keep the script
executing is to try to wrap it in whole into try-catch block. Uhmm...
Do you really want to try that?

So no, there is not anything close to what you are asking about.

Thanks.