Source line nr in serial output

Is there a way to include the source code filename + line number in a Serial.print statement?
Something like Serial.print(#linenr "an error occurred here").
It should ouput "myfile.ino - 123 - an error occurred here.
Would come in very handy for debugging purposes.

The short answer to your question is no

Have you get verbose output for compiling in your IDE preferences ? If not, then I suggest that you try it

Have you tried the preprocessor variable called __LINE__ and __FILE__


Serial.print(__FILE__);
Serial.print(": An error occurred line #");
Serial.println(__LINE__);
1 Like

Note that it will report the line number of the Serial.println(__LINE__) - which is not (quite) where the error actually occurred...

:stuck_out_tongue_winking_eye:

1 Like

fair :wink:

Serial.print(__FILE__);
Serial.print(": An error occurred line #");
Serial.println(__LINE__ -  3);

You probably can also use __FUNCTION__

void setup() {
  Serial.begin(115200);
  Serial.print(__FILE__);
  Serial.print(": An error occurred line #");
  Serial.print(__LINE__ - 3);
  Serial.print(" in function ");
  Serial.println(__FUNCTION__);
}

void loop() {}

you should see path/.../sketch.ino: An error occurred line #2 in function setup

1 Like

What type of errors are you trying to report on ?

@all: thanks for the valuable responses. This is exactly what I was looking for.

1 Like

@UKHeloBob: no particular type of error. The error message was just an example to clarify my question. I'm developing a device which uses Bluetooth and JSON to talk to a smartphone. There are a few thousand lines of code and several ino files where things can go wrong. Hence the need to pinpoint the area where the problem occurs.

A downside of this approach is that it takes a large amount of static text - which uses up a large amount of Flash storage. You haven't said which Arduino you're using, so can't tell how much of an issue that might be in this case.

Rather than store the whole message, filename, and line number in Flash, a more common approach is to just give an error code - which can be looked-up to see what it means, and where it happens...

1 Like

Fair point. I'm using ESP32. With Almost 450 k program memory I can get away with it.

1 Like

You also need to consider that a considerable amount of code will be executed after the Serial.print() before you actually see the message, because of how long it takes to actually send over Serial. You will likely never see the actual last message printed if the code crashes, unless you call Serial.flush() to force a wait until the transmit buffer is empty.

1 Like

You also need to consider whether you want the code to enter an endless loop at the point where the error occurs, to carry on regardless or for the code to somehow deal with the error and carry on

It seems to me that you would be better off programming defensively using techniques such as having the program calculate the number of elements in arrays rather than hard coding for loops to use fixed values. User input and input from external devices should be easy to validate and limit to sensible values and you will, of course, have tested the various parts of the sketch separately before combining them into a single sketch.

Another technique would be to introduce debugging prints to areas of the code likely to fail and to control whether they are compiled into the final sketch once you know that it is working. You could even go as far as logging progress through the sketch to an SD card for analysis in the event of a crash

Fair enough, but I'm not concerned in this case about what happens after the error. I'm not creating a controller for something critical like an RC car or a drone. If my code goes crazy after the error, so be it. If my code crashes I get a panic report from the ESP firmware and I can backtrack where (and in most cases why) the crash occurred.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.