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.

Apr 1 '08 #1

Richard Cornford

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.

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.

Apr 1 '08 #2

Richard Cornford

Don Li wrote:

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

<snip>

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

<snip>

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

Apr 2 '08 #3

rf

"Don Li" <ta********@gmail.comwrote in message
news:3b**********************************@d45g2000 hsc.googlegroups.com...

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

Apr 2 '08 #4

VK

On Apr 1, 10:07 pm, Don Li <tatata9...@gmail.comwrote:

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.

Apr 3 '08 #5

Don Li

On Apr 3, 2:50*pm, VK <schools_r...@yahoo.comwrote:

On Apr 1, 10:07 pm, Don Li <tatata9...@gmail.comwrote:

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.

Thanks.

Apr 3 '08 #6