Statalist


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: error mesage convention [was: Re: st: Importing data with infile: Identifying records with problems]


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: error mesage convention [was: Re: st: Importing data with infile: Identifying records with problems]
Date   Thu, 3 Sep 2009 11:33:36 +0100

Sergiy raises lots of issues, most of which are matters for StataCorp to
ponder. Indeed I suspect that they are fully aware of these wishes. 

We can all agree that user-programmers would all welcome and benefit
from better debugging facilities. 

But there is one repeated element in Sergiy's postings, both here and
previously, which I think is highly questionable. 

Sergiy is contrasting Stata unfavourably with the debugging facilities
characteristic of compilers, or integrated development environments, for
mainstream programming languages. 

I think this analogy is false, or at least of limited validity. The fact
of the matter is that the internals of Stata are not visible as they are
key to what is a proprietary product. That does not rule out better
debugging facilities for .ado files, but it does inhibit or prohibit
much of what Sergiy seems to be wanting. 

If anyone wants Stata to be more like R, they have an obvious
alternative, apart from cloning Stata, which would take a while. 

Nick 
n.j.cox@durham.ac.uk 

Sergiy Radyakin
===============

Hi Maarten, this is exactly the problem, without having the user's
input, I
don't know where the problem is, so the only choice is to ask to
send me the FULL trace of the program execution.

Last week I received three trace files. Largest of them was 615,915,398
bytes.
Reportedly there was an error 503 somewhere there. You may guess how
much
did it take to figure out where and why it happened? Or do you think it
was the
last line because Stata is smart to stop after an error?
[no, there is no such option to stop after an error or after an error
with a particular
error code]
Most users would not even want to bother with zipping that trace file.
"If the program
didn't work, why care?"

The majority of programs at SSC are single ado file and a single help
file. And
trace is quite helpful in developing and debugging those. (here a good
exercise
would be to look for mistakes in an average SSC file, e.g. here:
view http://fmwww.bc.edu/RePEc/bocode/a/appendfile.ado)

<snip> 

Maarten buis
============

> I think that we can safely assume that the people who made
> this decision where very well aware of this type of error
> message and thought very carefully about it.
>
> One reason that I would find convincing is that in the day
> to day use of Stata the fast majority of error messages is
> probably not generated by errors in programs, but by wrong
> inputs by the users. Moreover, the vast majority of users
> are not, and should not be, programmers, and often are
> intimidated by technical looking error messages. The way
> the error messages look now, are often very informative
> for those users.

Sergiy Radyakin
===============

>> When it comes to errors in .ado programs, it only tells
>> you the error code, but not the line number.
>>
>> At least basic error reporting in relation to the source
>> code is highly desirable and would make debugging .ado
>> files a much more pleasant task, ultimately improving the
>> quality of the code. See, how it was done in TurboPascal
>> in the 1980s



*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index