views:

316

answers:

5

OK. I may be splitting hairs here, but my code isn't consistent and I'd like to make it so. But before I do, I want to make sure I'm going the right way. In practice this doesn't matter, but this has been bothering me for a while so I figured I'd ask my peers...

Every time I use a try... catch statement, in the catch block I always log a message to my internal console. However my log messages are not consistent. They either look like:

catch(err) {
DFTools.console.log("someMethod caught an error: ",err.message);
...

or:

catch(ex) {
DFTools.console.log("someMethod caught an exception: ",ex.message);
...

Obviously the code functions properly either way but it's starting to bother me that I sometimes refer to "errors" and sometimes to "exceptions". Like I said, maybe I'm splitting hairs but which is the proper terminology? "Exception", or "Error"?

A: 

What you get in a Catch block is an Exception, so I name it as an exception...

If it is an error - I can handle it in my code & I usually don't expect to see it in the Catch block

HTH.

Sunny
+1  A: 

Exception is something you may expected for example in an attempt to open a file may face a "File not found exception". On the other hand, errors are something you may not see it coming like stack over flow or not enough memory.

An exception is an alternative logical way out off a function that does not produce a logical result. An exception also allows a better explanation of what happen why it exist this way. For File opening, again, a file handle is a logical result and if the file is not exist (one possible exception) or it is a folder not a file (another possible exception).

NawaMan
+1: This is similar to my thought on the subject. Exceptions can be expected, errors may not.
CAbbott
So if I understand you correctly, you suggest I should log based on what actually happens? That is, I determine when it's an error and when it's an exception? IE if it's a try/catch block around an AJAX call it's an exception, but an out of memory error is, well, an error?
Josh
An exception is an alternative way out off a function that does not produce a logical result. An exception also allows a better explanation of what happen why it exist this way. For File opening, again, a file handle is a logical result and if the file is not exist (one possible exception) or it is a folder not a file (another possible exception). It is this kind of situation I will use exception. So AJAX call should throw exception. :-D
NawaMan
+1  A: 

In JavaScript it is called Error Catching. So I would suggest you use error instead of exception. Leave the choice in the middle by using "e". Like in the examples of Mozilla. Mozilla Core JavaScript 1.5 Reference

CSmooth.net
Ahhh... but http://w3schools.com/js/js_throw.asp says "The throw statement allows you to create an exception."
Josh
w3schools is a set of tutorials, rather than a definitive reference site.
Daniel Earwicker
@Daniel: Thanks. That discredits CSmooth.net's answer
Josh
You can throw an exception. The catch statement catches that exception as an error. At least that is how W3C describes it. And so does Wikipedia and Mozilla.
CSmooth.net
+5  A: 

This is a bit subjective, but to me an error is when someone or something does something wrong, improper, or invalid. It could be a syntax error, a logical error, a read error, user error, or even a social error. It's an abstract concept.

An exception, on the other hand, is an object that is created and thrown when a certain condition occurs in code. It may or may not correspond to a conceptual error. So to me, the proper nomenclature is "exception".

tloflin
I like this -- it makes sense to me
Josh
OK. After a discussion on the subject with a friend, I'm seriously considering accepting this answer. Here's my thinking. Taking what you said with what @Pointy said in the comments: you can `throw` anything. Whatever `catch` catches is an exception. It may be that the exception is an error. Thus `Exception` is the proper term.
Josh
Thanks. I've hit my rep limit for the day, so feel free to take as much time as you'd like.
tloflin
@tloflin: Good for you. Well I'll accept later and that will give more people a chance to weigh in.
Josh
+2  A: 

The ECMAScript specification calls them exceptions. You might want to do likewise.

To make your logging more informative:

catch(ex) {
    DFTools.console.log("someMethod caught an exception of type " 
       + ex.name + ": ", ex.message);

You might also want to bear in mind that exceptions (unfortunately) can be of any type, and so don't necessarily have name and message properties:

catch(ex) {
    if (ex.message && ex.name) {        
        DFTools.console.log("someMethod caught an exception of type " 
           + ex.name + ": ", ex.message);
    } else /* deal with it somehow */

As this is starting to look pretty cumbersome to repeat everywhere, you might want to capture it in a function:

function logExceptions(methodName, action) {

    try {

        action();

    } catch (ex) {
        if (ex.message && ex.name) {        
            DFTools.console.log("someMethod caught an exception of type " 
               + ex.name + ": ", ex.message);
        } else {
            DFTools.console.log("someMethod caught a poorly-typed exception: " + ex);
        }
    }
}

Now you can say:

logExceptions(function() {

    // do some risky stuff...

});
Daniel Earwicker
HA! Actually the ECMAScript spec calls the "Error Exceptions"!
Josh
Yep, all the standard exception constructors use Error rather than Exception... but that's JS for you! :) But that is perhaps because those exception functions are supposed to indicate errors; other uses of exception may not. For example, JavaScript 1.7 in Mozilla has an extension called "generators" that uses an exception to indicate the end of a sequence, and the exception type is `StopIteration` - no mention of "errors", which makes sense. So there may be some method to the madness...
Daniel Earwicker
@Josh - my reply above is to your original comment before you edited it, in which you asked why the built-in exception constructors use the word "Error". The new reply is: what spec are you reading? The version I linked to refers to exceptions as "exceptions". It uses the term "error exception" to refer specifically to exceptions that indicate errors. That's not all exceptions.
Daniel Earwicker
@Daniel: Sorry. I posted before I had read everything, that's why I edited my comment. I see now there are `Errors`, `Exceptions`, *and* `Error Exceptions` defined in the spec... Leading me to think I should change my code entirely to detect of the caught object is an Error or an Exception...
Josh
It depends; if you're just logging it, why not simply incorporate the name of the exception type into the message?
Daniel Earwicker
@Daniel: I do. But my messages typically say `"Caught an exception/error: "+e.message`
Josh
Okay - my point is, if you include the `ex.name` in what you log, you will be able to see if it's an error or whatever, with no need to categorize it in any other way. Also I've added some thoughts on dealing with other problems.
Daniel Earwicker
Ah ha. Great code example. Thanks!!
Josh
@Daniel: I'm going to leave the question open for a bit, but I like your idea and I am standardizing everything into a single call which logs the error, and prints it's name, based on the code you suggested. Great answer!
Josh