Is there a way to point to the code where the error happened in Rust? - error-handling

I have the line and file in which an error happened using the line! and file! macros respectively. The Rust compiler is able to point to exactly where the cause of the error in the source code happened. Is there a way to point to a specific area in the code where the line = line! and the file= file!?

It is not really clear what you are trying to do, but I think you are looking for crates that can format error messages like the Rust compiler, for example:
codespan-reporting
annotate-snippets
codemap
or you might take a look at the source code for error reporting in the the Rust compiler, but it uses its own module which is not usable from outside the compiler itself.

In Visual Studio Code you can hold Ctrl and click on the line number in the panic and it will jump to the line in the editor.
For example when you run your program in the integrated terminal you might get:
thread 'main' panicked at 'explicit panic', src/main.rs:27:5
^
|
CLICK HERE -/

Related

Is there a function or crate to display errors with line and column numbers, help text, and highlighting?

Rust has very clear error display, showing the line and part of line where an error occurred:
Is there a function from the Rust standard library or crate which replicates this for an arbitrary error? I'm kind of assuming it must exist somewhere within the Rust codebase, but can't find anything (mostly because any search term like "Rust rich line errors..." returns errors people have got while writing Rust, not how to generate the error display :-)).
E.g. I have the line number and character number of an error as well as the source, is an existing implementation of the above pretty error which I can reuse?
I don't know if this is of much help, but the rustc compiler uses the rustc_errors crate to generate these messages. I found this by looking at the README in librustc and searching the guide book for "message".
The search brought me to this section in the guide which covers error messages.

Invalid floating point operation while loading dll

I got a problem recently that when I added a code to a lib, which is used by a dll, the dll cannot be loaded. I get an exception "Floating point invalid operation at xxx". When I comment out the code it works. The code added is just straight forward like creating a TADOQuery object, add the sql statment and the parameters, then do an open, check value etc. Nothing suspicious. Now when I uncomment the code and comment another chuck of code in the unit elsewhere, it starts to work. So obviously the newly added code was just tripping the issue caused elsewhere.
Now this error happens when LoadLibrary() call is invoked. There is no attach code. The DllMain, just has a return 1. When this happens the assembly code is always at FSTP tbyte ptr doing a System::Variant::Clear().
Anyone has come across such issues? Any tips on how to debug is also appreciated.
PS: It could also be Embarcadero's compiler issue. I recently figured out that the assembly generated for a combination of assignment and comparison is incorrect. The only suspicion here is the lib that the dll uses is large. When I do a clean and build of the lib, the total lines shows 5.7m. Maybe there is some setting for large libs?
IDE-XE4, c++ builder
OS-Win 7
Thanks,
Mathew Joy
C++Builder and Delphi have different default FPU settings than, say, MSVC and the DLLs written in it.
It probably goes like this: After DllMain, certain exceptions are masked to be hidden. But before the first floating point operation in C++Builder code occurs, that exception is unmasked and the exception occurs.
This is a known problem with C++Builder/Delphi floating point and DLLs.

Find potential problems through log files

If there is a problem in the source code, usually a programmer goes through the log manually and tries to identify the problem in the source code.
But is it possible to automate this process? Can we automate the process that would give the potential lines in the source code that was responsible for generating the fault.
So, for example:
If there is some problem in the log file. Then this automation tool should say that this problem has occurred due to line 30,31,32,35,38 in source code ABC
Thanks!!
It depends on the language you are using.
In Java (and probably other JVM languages) this feature is built-in: Every exception that is thrown has a reference to the stack trace, including class, method and line number of every method involved. All you need to do is something like
exception.printStackTrace();
In C and C++, you can use preprocessor macros like __FUNCTION__ or __LINE__ when throwing an exception or writing a log message, for example:
throw "Error in " + __FUNCTION__ + ", line " + std::to_string(__LINE__);
The macros will be replaced by the current function and the current line.
If you are looking for a method that works with any language and any type of logging, there is no good solution. You could run a tool like grep over all source files, that will try to find matches. However this will only work if the log messages appear as string literals in source code at the position where the message is written. This is unlikely because the messages are likely to contain variable values or constants defined somewhere else.
Assuming we are not talking about (unit) testing, because this is what they do - show you where is the problem exactly.
Then this automation tool should say that this problem has occurred due to line 30,31,32,35,38 in source code ABC
In my team we had similar discussion and what we've come with is a Top5 most likely issues document (PlayBook). After reading logs every time on failure, we've noticed that in most of the times there is a requiring pattern. So 8 out of 10 cases the issues were following one of those patterns. So it is possible to trace the latest changes (with the help from Git). If your changes are small and frequent - this approach works quite well.

Ambiguous "User-defined type not defined" Error

Generally, when the "User-defined type not defined" error occurs, a piece of code within the project is brought up on the VB6 UI and highlighted to show the user which user-defined type the IDE is unable to make an associate with.
In my case, however, no frame/code is popping up for this error, leaving me no idea which user-defined type this atrocious piece of software is unable to find.
This project is huge and includes hundreds of different references and components. Project -> References shows nothing is "missing". Any ideas for how to find out what user-defined type the IDE is unable to find?
Try setting project compatibility on every project in the group and start the application with Ctrl+F5 in the IDE.
Try compiling from command line -- check out vb6.exe /? for more info.

program's printf backslash n does not carriage return when compiled with Eclipse

I handed in a C program which contained a lot of verbose printf debug lines. I always compiled it command line with gcc.
Now it's been turned into an Eclipse-CDT (Helios) project, and my
\n
no longer do carriage returns. I get an unreadable "staircase" in my console.
RCINAHFM. Is there a check box in the IDE I need to modify or do I need to go back and carefully modify hundreds of lines of code?
Any help greatly appreciated.
Bert
RCINAHFM=Remaining calm / I need a hug from Mom
Eclipse does not compile C all by itself. It uses an external compiler for that, usually gcc. So it’s highly unlikely that the compiled program is incorrect, unless the compiler configuration within Eclipse does something very, very weird.
If you get a “staircase”, it sounds as if the new line part is carried out, but no carriage return happens. This might happen under systems that use CR/LF as their line ending, such as DOS/Windows.
Unfortunately, you give way to little detail. Are you using Unix or Windows? Where does the program run, in an XTerm, a Windows DOS console, within the Eclipse console? If the answer is “Eclipse console”, then have you tried running it in another terminal instead; or tried running your original program in the Eclipse console? Are you using printf or some other function?