h a l f b a k e r yIf you can read this you are not following too closely.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Maybe I'm being a little naive here, but wouldn't it be great to have a compiler that actually told you what was wrong.
Posible messages should include: you've put that bit in the wrong place, it should go there, you've forgotten to do that, etc
(?) "Funny" error messages
http://home.xnet.co...nis/unix_humor.html To stem the tide. [egnor, Oct 21 2000, last modified Oct 04 2004]
Parentheses tracker
http://www.halfbake...rentheses_20tracker An idea for Nobody. [juuitchan3, Jun 29 2002, last modified Oct 04 2004]
[link]
|
|
I used to be consulted daily on Fortran problems in a large engineering firm. I was reminded of Robert Pirsig's comments on paying attention and thinking about what you are doing when you are doing it. |
|
|
"I can't figure out why my program crashed." |
|
|
I look at the printout. "ERROR: YOU HAVE DIVIDED BY ZERO IN LINE 420." |
|
|
"Have you considered the possibility that you have divided by zero in line 420?" I ask politely. |
|
|
To report the kind of error message you want, the compiler has to somehow know what you meant so that it can tell how what you wrote down is different. |
|
|
If we could make compilers which were able to intuit your meaning from buggy code you wrote, well... |
|
|
The best we can really hope to do is provide enough information about what the compiler was doing when it encountered the error, and why the error occurred, that the programmer can match this against their mental model and track down the problem. |
|
|
My devtool of choice, Delphi, has the decency to give me plenty of hints where it sees I've left loose ends in my code. That's a start, I suppose. |
|
|
It would be really cool if the compiler could go a step further, work out what the mistyped variable name should have been (hey, its toted up the symbols already!), and perhaps working out where the missing END; should go. |
|
|
I am reminded of a story (web urban legend?) where some version of a C compiler went out the door with some of the developer's "test" error messages still in place. It was not too long before they got a call asking what the following compiler error meant: |
|
|
Error 3040: Klingons off the starboard bow |
|
|
A number of compilers do attempt "error recovery", e.g. "working out where the missing END; should go". Many such compilers will even tell you exactly what they're doing: "inserting END; before line 135". |
|
|
It sucks. They guess wrong, and you just get a whole pile of "snowball" errors. |
|
|
Or, alternatively: Compilers that swear at you if get something wrong: |
|
|
eg: "You ****ing idiot, you missed out a ;", or "Everbody knows you dont do that you cretin". |
|
|
Error 1500: Better software that does the same task already exists as off-the-shelf. |
|
|
Error 1501: Your user-model is lousy and no one but a code-head will be able to figure out the UI. |
|
|
Error 1502: I could have written this using 2110 fewer lines of code. |
|
|
Error 1503: Lines 13900-14560 violate 3 current software patents. |
|
|
Error 1504: It's obvious this was written without the benefit of a proper Software Requirements Specification. |
|
|
Imho, it would be good if we moved away from C-style syntax. If, instead, you have to write something like |
|
|
do i=1,10
call doSomething()
enddo |
|
|
you'll be less likely to make mistakes like this: |
|
|
for(i = 1; i <= 10; i++);
doSomething(); |
|
|
Hey nobody. Get yourself some Delphi: |
|
|
for i := 1 to 10 do
begin
Something;
Something else;
end; |
|
|
My lisp interpreter deals with runtime errors as follows: |
|
|
Error: Can't evaluate <some expression>
Evaluate instead: <read expression>
Replace?(t/nil):
<value that would have been returned if evaluate instead expression were where some expression was> |
|
|
In the event that <some expression> is a list, it puts a
<exp>-><value> entry for each element between Error: and Evaluate instead. This makes obvious situations where I've used an inappropriate number of arguments or inappropriate argument type, without maintaining a collection of error messages. |
|
|
Debugging Java from (Sun) compiler errors is dead easy 99% of the time. |
|
|
This is not a compiler error but a command line error on my terminal that keeps me amused when things are slow...
<enter command> God
<error message> 'God' does not exist. |
|
|
See link, before anyone posts more... |
|
|
Nobody: I have a similar idea. |
|
|
Halfbaked enough to have an acronym: DWIMNWIS. |
|
|
<error message> 'God' does not exist. - DrBob, |
|
|
What would he have done if it had worked.... |
|
| |