Best practices for error handling

[Conrad Lender]

I'd like to hear your opinions about the appropriate way to deal with
non-critical errors that can occur in user-defined functions. For
example, an application chooses to extend String.prototyp e with a
format() method similar to sprintf(). Several formats (%d, %f, etc) are
supported, but %z would be invalid. During the parsing of the format
string, the function encounters an invalid format which (most likely)
was caused by a programmer error.

Should it:

- try a best-guess resolution and continue?

- fail silently (returning an empty or partial result)?

- throw an exception? If so, which one (a string, a user-defined object,
one of the built-in Exception objects)?

- display an alert()?

- do something else?

The target clients are modern browsers, and exceptions are available.
At the moment, I'm using a mix of the above; something similar to this
(reduced example):

function warn (msg) {
if (window.console && typeof window.console. error == "function") {
// If the Firebug console is available, display the error, but
// allow the calling function to continue
window.console. error(msg);
} else {
throw new MyCustomExcepti on(msg);
}
}

but I'm not happy with it, because the program flow is different
depending on the availability of Firebug. The format() method may want
to signal a non-critical error, but still try to continue. I guess what
I'm looking for is a way to issue warnings without Firebug. I'd rather
not use alert(), because there could be a large number of warnings when
things go wrong.


- Conrad

[Dr J R Stockton]

Re: Best practices for error handling

In comp.lang.javas cript message <jKqdnapQFYWXKp nUnZ2dneKdnZydn Z2d@supern
ews.com>, Sun, 26 Oct 2008 19:29:30, Conrad Lender <crlender@yahoo .com>
posted:

>I'd like to hear your opinions about the appropriate way to deal with
>non-critical errors that can occur in user-defined functions.

That must depend on the purpose of the page being displayed.

For an "advertisin g" page, the code should probably do its best to
continue, while avoiding making false statements to the reader. But one
might have a test mode, maybe set by the contents of a small include
file or by a special input or by editing a var debug=0; statement.

For an "ordering" page, similar but more cautiously.

For an "instructional" , "calculatin g", or "within-business" page, it's
better to enter a diagnostics mode, proceeding with the original task
only so far as is safe.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demo n.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)

[dmark@cinsoft.net]

Re: Best practices for error handling

On Oct 26, 2:29 pm, Conrad Lender <crlen...@yahoo .comwrote:

I'd like to hear your opinions about the appropriate way to deal with
non-critical errors that can occur in user-defined functions. For
example, an application chooses to extend String.prototyp e with a
format() method similar to sprintf(). Several formats (%d, %f, etc) are
supported, but %z would be invalid. During the parsing of the format
string, the function encounters an invalid format which (most likely)
was caused by a programmer error.
>
Should it:
>
- try a best-guess resolution and continue?

No.

>
- fail silently (returning an empty or partial result)?

Not a partial result. Return null if it fails.

>
- throw an exception? If so, which one (a string, a user-defined object,
one of the built-in Exception objects)?

No.

>
- display an alert()?

Of course not.

>
- do something else?

In addition to returning a "falsy" value (other than undefined of
course) to signal a mistake, clearly document the expected syntax for
the argument(s). At that point it is up to the developer to read the
instructions and handle failures in ways that suit their applications
(some might even want to use alerts.)

>
The target clients are modern browsers, and exceptions are available.
At the moment, I'm using a mix of the above; something similar to this
(reduced example):
>
function warn (msg) {
   if (window.console && typeof window.console. error == "function") {
      // If the Firebug console is available, display the error, but
      // allow the calling function to continue
      window.console. error(msg);
   } else {
      throw new MyCustomExcepti on(msg);
   }
>
}
>
but I'm not happy with it, because the program flow is different
depending on the availability of Firebug. The format() method may want

Yes, that is less than ideal.

to signal a non-critical error, but still try to continue. I guess what
I'm looking for is a way to issue warnings without Firebug. I'd rather

Then you need to create an object that updates the value of a
TEXTAREA. Optionally, it could echo the messages to the browser's
error console (if the feature is available.) Firebug is not needed at
all.

[Conrad Lender]

Re: Best practices for error handling

On 2008-10-28 04:14, dmark@cinsoft.n et wrote:

>I guess what I'm looking for is a way to issue warnings without Firebug.

>
Then you need to create an object that updates the value of a
TEXTAREA. Optionally, it could echo the messages to the browser's
error console (if the feature is available.) Firebug is not needed at
all.

That's a good idea. I could try to add support for other error consoles
than Firebug. I think Opera and Safari allow scripts to print messages
to their consoles; IE doesn't; not sure about Mozilla. I'll have to look
that up.

And you're right, warnings should never result in exceptions, only
non-recoverable errors should do that. A textarea may not be available,
and the DOM may not be ready at the point when a warning should be
issued. But I can store the warnings and let them be retrieved later.
That way the page that uses the library can decide how to handle or
display them.


- Conrad

[David Mark]

Re: Best practices for error handling

On Oct 29, 12:05 pm, Conrad Lender <crlen...@yahoo .comwrote:

On 2008-10-28 04:14, dm...@cinsoft.n et wrote:
>

I guess what I'm looking for is a way to issue warnings without Firebug.

>

Then you need to create an object that updates the value of a
TEXTAREA.  Optionally, it could echo the messages to the browser's
error console (if the feature is available.)  Firebug is not needed at
all.

>
That's a good idea. I could try to add support for other error consoles
than Firebug. I think Opera and Safari allow scripts to print messages
to their consoles; IE doesn't; not sure about Mozilla. I'll have to look
that up.

I believe the old Mozilla browsers have an error console. I know
NN6.2 has one.

>
And you're right, warnings should never result in exceptions, only
non-recoverable errors should do that. A textarea may not be available,
and the DOM may not be ready at the point when a warning should be
issued. But I can store the warnings and let them be retrieved later.
That way the page that uses the library can decide how to handle or
display them.

Yes. That is exactly what I do.

[sasuke]

Re: Best practices for error handling

On Oct 29, 9:05 pm, Conrad Lender <crlen...@yahoo .comwrote:

And you're right, warnings should never result in exceptions, only
non-recoverable errors should do that. A textarea may not be available,
and the DOM may not be ready at the point when a warning should be
issued. But I can store the warnings and let them be retrieved later.
That way the page that uses the library can decide how to handle or
display them.

Returning `null' and pushing the error / warning message in the
library's custom error queue which can be retrieved at any point in
time by the developer indeed seems like a good solution.

../sasuke