Crate Idea for semester project

Hey guys, i'm just developing a idea for a crate as part of my semester module in university.
The topic is: solution suggeestions for run time errors.

So basically a wrapper for the particular function which evaluate the return value and in case of a error it sends a request to stackoverflow and shows the most upvoted solution.

Because i'm less experienced with rust now my question to you: What would you recommend as strategy to develop this idea?

greetz

Maybe create a procedural macro attribute which parses the function body and adds more code to communicate errors to your frontend. The idea is to non-intrusively handle errors without code accommodation within your target. There might be a lot of edge cases, and writing a procedural macro is complicated for a first-timer but there are plenty of examples already.
A primitive version of this could detect usage of the question mark operator, which is the shorthand of "if this returns an error, return that error immediately. else unpack the Ok-value."
It's an idea i'd like to explore myself as well.

The frontend could be a message on stdout with a link or maybe a window you build yourself to make it more fancy.

Use the Syn crate for parsing function body tokens.

I am not sure this is a good idea. Often the upvoted solution might not be the best and better solutions get developed over time. Also you may be a victim of the XY Problem

@dylan.dpc the solution suggestion should more be used as a helper. Instead of copy pasting error messages which i not understand, the framework gives u directly links to SO or any other kind of helping resources. It should not give the ultimate solution that you need to assume.

There's a young project trying to make Rust's panic messages more user-friendly. Perhaps you could help with this?

https://github.com/yoshuawuyts/human-panic

Rust's non-panicking errors (Result<_, Err>) are strongly typed, and there are crates such as error chain and failure that aim to add more context to the errors. Maybe you could try extracting a good search query from this data (e.g. maybe compute a globally uniquely-identifying error ID for each error to help finding error messages on the web).

2 Likes

Thank you for the comment @kornel. I will take a look :slight_smile:

@Bert-Proesmans Thank you for the Answer, it really helped me to develop my idea of the project.

I have currently two approaches where I cannot decide which one is the better idea or has the better use case.

The first one: catching runtime errors in rust is kind of boring because rust hasn't that much runtime errors, much more while compile time. Furthermore, there are not many (i didn't even found once) example of a runtime error in StackOverflow. Runtime errors in rust are basically self-made by panic!() and are often found in extern dependent crates. But I couldn't test it appropriately because StackOverflow hasn't issued about runtime errors from extern crates (as I researched).

The second one: It would be nice to refer compile-time errors to StackOverflow. The docs aren't always understandable and it would be good if you have some other helping resources from SO. So then I would need to wrap a broken program to analyze the compile errors and give an adequate output with links referring to possible solutions. But the most Editors have already builtin cargo servers which check compile errors in real-time.

In the one hand, I need to catch runtime errors which basically not issued on Stackoverflow or in the other hand refer compile-time errors to better-explained solutions, although there are good builtin cargo servers which do the same but with Rust docs.

What do you think would be the better use case? Or maybe you have another suggestion?

greetz

Sorry for the late reply, i had to think about your questions for a while.
Those are very different things, it depends on where your interest lies.

The first can be achieved by building or contributing to existing crates which handle runtime errors, like human-panic. Though most of the errors you'll encounter will already be defined by the code implementers. Augmenting a panic! without much context is tough to find stackoverflow references for.

The second is only possible (imo) if you contribute to the compiler itself. I don't know how to help you further in that regard.

Errors are in general a difficult issue to tackle, so i wish you good luck. Something will come out of it eventually, but after a lot of experimentation i'm afraid.

A safe abstraction layer crate for system V shared memory would be really nice ... and I'm not telling you this because I need this :joy:

1 Like