Error Object ("Class") Manipulation

[SMH]

I am not a big user of the try/catch/finally blocks: it seems like a lot
of code clutter. (I hope some avid proponent of its usage can dis-abuse
me of this prejudicial feeling I have.)

However, I would like to use code that 'throw's errors as part of user
interfaces/input checking.

Thus:

if (inputCheck(userInput) == "sucks")
throw anError;

The identifier 'anError' might be:

anError = alert("some message");

anError = new Error(parameters);

What I am wondering is if the Error constructor code can be altered
somehow to include within it a call such as alert() or something similar.
A lot of monographs and one "bible" on Javascript show 'throw' operators
being used to invoke the 'catch' block (must it only be used for that?)
and then the scripter handles as he wants.

Or perhaps the Error constructor might be able to contain code to re-write
itself, with either an instance of itself being re-written or perhaps the
static object being manipulated, if there is such a thing as a static
object.

Can anyone enlighten me on the use of functions/constructors that re-write
themselves or which may be re-defined/re-written on page load, and if this
can or should be done with the built-in Error object? What have you
experimented with?

 

[Joost Diepenmaat]

I am not a big user of the try/catch/finally blocks: it seems like a lot
of code clutter. (I hope some avid proponent of its usage can dis-abuse
me of this prejudicial feeling I have.)

However, I would like to use code that 'throw's errors as part of user
interfaces/input checking.

Thus:

if (inputCheck(userInput) == "sucks")
throw anError;

The identifier 'anError' might be:

anError = alert("some message");

anError = new Error(parameters);

What I am wondering is if the Error constructor code can be altered
somehow to include within it a call such as alert() or something
similar.

Even if it could, you probably don't want to. Exceptions that are caught
aren't generally supposed to be user-visible. IOW, you don't want to
alert() when *creating* the error, you can to alert() if the error
*isn't* caught - which may or may not be possible; the user agent
probably already has its own ways of dealing with that situation.

A lot of monographs and one "bible" on Javascript show 'throw' operators
being used to invoke the 'catch' block (must it only be used for that?)
and then the scripter handles as he wants.

Yes. That's what it's for. You throw an exception to some catching code
higher up the stack which should deal with the situation. If you don't
catch the exception, it halts the program.

This also means you can do something like:

try {
if (inputCheck(userInput) == "sucks")
throw "stuff";
if (...) throw "other stuff";
}
catch (e) {
alert(e)
}

Or perhaps the Error constructor might be able to contain code to re-write
itself, with either an instance of itself being re-written or perhaps the
static object being manipulated, if there is such a thing as a static
object.

I wouldn't know what that's supposed to accomplish.