how to show line number

[lovecreatesbeauty]

Hi javascript world, It's 2011, is there a way to show line number of
the source code in a javascript / html file, like the __LINE__ thing
in C and PHP.

 

[Jukka K. Korpela]

Hi javascript world, It's 2011,

Thanks for the update!

is there a way to show line number of
the source code in a javascript / html file, like the __LINE__ thing
in C and PHP.

I don't think so. But what would you do with it? Developers are supposed
to use debugging and inspecting software. End users are not supposed to
need to know about line numbers of code.

 

[John G Harris]

Hi javascript world, It's 2011, is there a way to show line number of
the source code in a javascript / html file, like the __LINE__ thing
in C and PHP.

The line number on its own isn't much use if you're not told which of
several files it belongs to.

John

 

[jianhua]

I don't think so. But what would you do with it? Developers are supposed
to use debugging and inspecting software.

Are the debugger and inspector useful?

Can I just test and check html and javascript code just in and by
browsers?

End users are not supposed to
need to know about line numbers of code.

I think users can report the errors along with the line numbers to
developers.

 

[jianhua]

The line number on its own isn't much use if you're not told which of
several files it belongs to.

Each file reports its own filename by __FILE__ and line number by
__LINE__ .

External files are introduced by <script src="foo.js"></script> .

Html and javascript don't have other file includes, right?

 

[Tim Streater]

Are the debugger and inspector useful?

Can I just test and check html and javascript code just in and by
browsers?


I think users can report the errors along with the line numbers to
developers.

In Safari, you can look in the web inspector and see something like this:

TypeError: Result of expression 'sigselPtr.options' [undefined] is
not an object. mypage.html:945

That tells me what happened and where.

If you want to log that, use window.onerror which will give you the
three elements of the error above: message, url, and line-number. You
can then do what you want with that.

window.onerror will be available in Safari 5.1 when that's released, but
I think other browsers already support it.

 

[Lasse Reichstein Nielsen]

Each file reports its own filename by __FILE__ and line number by
__LINE__ .

External files are introduced by <script src="foo.js"></script> .

Html and javascript don't have other file includes, right?

Well, you can fetch the source using XMLHTTPRequest, and then evaluate it.

In any case, textually replacing __FILE__ and __LINE__ by a string or number
literal sounds like something that could and should be done by the server.

You could do it on the client, if you use eval.

But again, without the C macro preprocessor, I can't really see a use
for it. The line won't move from where you wrote it.
If you have your own preprocessor that combines scripts - that would be
the place to put the substitution too.
/L

 

[Scott Sauyet]

Well, you can fetch the source using XMLHTTPRequest, and then evaluate it.

In any case, textually replacing __FILE__ and __LINE__ by a string or number
literal sounds like something that could and should be done by the server.

I'm sure that given some time I could get something to work in most
browsers; but I'm not sure about IE. It's not as hard as it sounds:
write a function to throw an catch an exception, then examine the
lines of the stack trace, which in most browsers have the file name/
url and line numbers.

But I can't see a real need for this.

-- Scott

 

[Jukka K. Korpela]

I'm sure that given some time I could get something to work in most
browsers; but I'm not sure about IE. It's not as hard as it sounds:
write a function to throw an catch an exception,

That occurred to me too; then I realized that throwing an exception
would be rather brutal and could cause harm.

But I can't see a real need for this.

I can't imagine a disease for which this cure could be useful. In
typical situations, any cure would be worse than the suspected disease.

 

[Dr J R Stockton]

In comp.lang.javascript message <0451adda-0284-4c14-b8b7-fdf0b68b1f97@y7
g2000prk.googlegroups.com>, Thu, 23 Jun 2011 09:42:06, jianhua

Are the debugger and inspector useful?

Can I just test and check html and javascript code just in and by
browsers?

In author's testing, it is often sufficient to use the Error Console,
and much simpler than using debuggers.

I think users can report the errors along with the line numbers to
developers.

You can use try/catch around anything you consider dangerous, and make
it produce a suitable action. There's an example in
<http://www.merlyn.demon.co.uk/estrdate.htm#CEDL> line 1451, in
function ReadEasterFile, where current Chrome will not work (failure is
after pressing "Test File").

I suspect Jukka thinks web users can be divided into two classes -
professional developers, and readers. There is a significant
intermediate class of amateur page authors, who write not for money but
because they have something to say. H'mmm - I forgot two other classes;
teachers, and TL.

 

[Jukka K. Korpela]

In author's testing, it is often sufficient to use the Error Console,
and much simpler than using debuggers.

I'm not sure what you mean by "Error Console", but I would expect it to
fall into the category of debugging and inspecting software. Using IE 9
for example, you just need to press F12 to get to see errors with line
numbers.

Developers are supposed to find out the line numbers. In error reports,
it is far more important to describe what you did and what happened than
to do the developer's work.

You can use try/catch around anything you consider dangerous, and make
it produce a suitable action.

Is this related to the issue of finding line numbers? If you expect
users to tell line numbers in bug reports, I don't see how that assumed
need would vanish if you use try and catch.

I suspect Jukka thinks web users can be divided into two classes -
professional developers, and readers.

There are developers and there are users, but the dichotomy is all yours.

There is a significant
intermediate class of amateur page authors, who write not for money but
because they have something to say. H'mmm - I forgot two other classes;
teachers, and TL.

This is irrelevant to the issue of showing line numbers. If it is
relevant to you to find source line numbers of JavaScript code, you can
find them using debugging and inspecting software.

 

[Tim Streater]

I'm not sure what you mean by "Error Console", ...

In Safari,if you enable the Develop menu (in the Prefs), then it's
simply Develop -> Show Error Console.

C'mon laddie, you should know this.

 

[Thomas 'PointedEars' Lahn]

I'm not sure what you mean by "Error Console", but I would expect it to
fall into the category of debugging and inspecting software.

Not necessarily.

Using IE 9 for example, you just need to press F12 to get to see errors
with line numbers.

Try Opera.

Developers are supposed to find out the line numbers. In error reports,
it is far more important to describe what you did and what happened than
to do the developer's work.

False dilemma.

Is this related to the issue of finding line numbers? If you expect
users to tell line numbers in bug reports, I don't see how that assumed
need would vanish if you use try and catch.

See above.

There are developers and there are users, but the dichotomy is all yours.

Then your logic is flawed.

There is a significant intermediate class of amateur page authors, who
write not for money but because they have something to say. […]

This is irrelevant to the issue of showing line numbers. If it is
relevant to you to find source line numbers of JavaScript code, you can
find them using debugging and inspecting software.

No, that there are people who are both developers and users suggests that
simplified error messages including information like line numbers can be of
value.


PointedEars

 

[Jukka K. Korpela]

Try Opera.

I don't need your help to choose a browser.Your trolling is getting more
and more pointless (pun intended), as you just throw (no pun intended)
irrelevant notes in midst of texts you quote from others.

No, that there are people who are both developers and users suggests that
simplified error messages including information like line numbers can be of
value.

Yet you haven't said how it could be done; you just make pointless
remarks, that's all.

And of course the logic is faulty: developers (whether they are also
users, or red-haired, or vegetarian) benefit much more from the use of
inspecting and debugging software than they could benefit from line
numbers shown with JavaScript tools (if you could tell them how to get
them). Telling them how to generate the line numbers would just inhibit
natural learning. Whining about the need for the line numbers without
telling anything constructive is of course even worse.

 

[Lasse Reichstein Nielsen]

Jukka K. Korpela wrote:

Try Opera.

I always recommend trying Opera
In this case it's Menu>Page>Developer Tools>Error Console.
Could be faster, but if you use it often, you can add a button to the UI:
http://operawiki.info/CustomButtons#webdev

/L

 

[Dr J R Stockton]

I'm not sure what you mean by "Error Console", but I would expect it to
fall into the category of debugging and inspecting software. Using IE 9
for example, you just need to press F12 to get to see errors with line
numbers.

It is what one gets by selecting the menu item "Error Console" in
Firefox and in Opera. My other browsers seem not to offer anything
quite as simple and convenient, though they do have something more
potent.

Is this related to the issue of finding line numbers? If you expect
users to tell line numbers in bug reports, I don't see how that assumed
need would vanish if you use try and catch.

It means that you can give the users a clear statement of the problem,
with a unique identifying number if you like. Line numbers are of no
use as such; there are merely one way of finding lines. By providing a
reportable reference with try/catch, one removes concern about exactly
how the lines are numbered and which version of your code is being used.

Just give a reference of JKK: followed by the current yyyyWwwd-hhmmss at
the time of authoring the message, and uniqueness is virtually
guaranteed.

 

[Dr J R Stockton]

In comp.lang.javascript message <timstreater-0E873B.09534825062011@news.
individual.net>, Sat, 25 Jun 2011 09:53:49, Tim Streater

In Safari,if you enable the Develop menu (in the Prefs), then it's
simply Develop -> Show Error Console.

C'mon laddie, you should know this.

Indeed. But what you get in Safari appears rather potent, and the
simpler console of Firefox or Opera is often entirely sufficient.

 

[Thomas 'PointedEars' Lahn]

I don't need your help to choose a browser.

This was not about choosing a browser for everyday browsing, but to see
the difference between an error console and a debugger. Your obnoxious
arrogance has made you blind to the possibilities.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Tim Streater posted:

Indeed. But what you get in Safari appears rather potent, and the
simpler console of Firefox or Opera is often entirely sufficient.

However, it should be noted that the built-in "Error Console" of Firefox
2.0+ (indeed, the "JavaScript Console" of Mozilla-based browsers even before
Mozilla.org) differs from Opera's in the regard that it can be used as a
direct, yet limited, debugging tool indeed:

Besides being able to show errors (which an error console does), it provides
a way to evaluate arbitrary statements and to display the result of the
evaluation. AFAIK, Opera's does not, you would need the Dragonfly developer
tools for that.


PointedEars

 

[Thomas 'PointedEars' Lahn]

I always recommend trying Opera
In this case it's Menu>Page>Developer Tools>Error Console.
Could be faster, but if you use it often, you can add a button to the UI:
http://operawiki.info/CustomButtons#webdev

It is Tools → Advanced → "Error Console" here (Opera 11.11.2109 for Linux),
and the keyboard shortcut Ctrl+Shift+O is attached to it by default (it is
Ctrl+Shift+I for Dragonfly in the same submenu). Those are shortcuts to
remember (and easily remembered).


Regards,

PointedEars