wstd::main doesn't set exit code on failure
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 45/100
Rechercherichtung
Beginne damit, die Implementierung von #[wstd::main] zu finden und nachzuverfolgen, wie ein Result-Fehler die wasi-run-WIT-Schnittstelle durchquert. Vergleiche sein Verhalten mit dem im Issue beschriebenen tokio::main-Muster. Die Aufgabe ist erfüllt, wenn ein fehlschlagendes async main einen Exit-Code ungleich null zurückgibt und der Fehler nicht stillschweigend verworfen wird.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
When using the #[wstd::main] i would expect that an error would set another exitcode than 0.
This beavior is the same right now as tokio::main in a none wasm-application.
Example usage:
use std::error::Error;
use wstd::http::{Body, Client, Request};
#[wstd::main]
async fn main() -> Result<(), Box<dyn Error>> {
let request = Request::get("https://non-existing-url.example.com")
.body(Body::empty())?;
let _response = Client::new().send(request).await?;
Ok(())
}
This will return Exit-code 0 when compiled to wasip2 through the wasi-run WIT-interface, and the error form the application will be throwed away between the wit-interface.
Is this the intended behavior?
For example right now i have to do this to make my "main" applications async
use std::error::Error;
use wstd::http::{Body, Client, Request};
fn main() {
wstd::runtime::block_on(async move {
if let Err(err) = async_main().await {
eprintln!("{err}");
std::process::exit(1);
}
});
}
async fn async_main() -> Result<(), Box<dyn Error>> {
let request = Request::get("https://non-existing-url.example.com").body(Body::empty())?;
let _response = Client::new().send(request).await?;
Ok(())
}
- Vorherrschende Sprache
- Rust
- Sterne
- 138
- Forks
- 21
- Ø Merge
- 5 T. 12 Std.
- Gemergte PRs (30 T.)
- 7
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus bytecodealliance/wstd
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
bytecodealliance/wstd#166 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
bytecodealliance/wstd#164 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 55/100
bytecodealliance/wstd#151 ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 32/100
bytecodealliance/wstd#141 · 6 Kommentare · 1 Reaktion ·
-
Add `wstd-azure`Evtl. wieder frei @yoshuawuyts hat das vor 341 Tagen übernommen, und es ist kein Pull Request offen. Offenenhancement
bytecodealliance/wstd#104 · 1 Reaktion · 1 zugewiesene Person ·
Alle Issues in bytecodealliance/wstd
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
bmander/geomsolver#118 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Three Windows builds are keyed on a later release than their layoutEvtl. vergeben @ero-qt hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 95/100
Maintainer antworten meist innerhalb von 1 Tag
-
Markdown Preview Fonts Don't Show Selected OptionEvtl. vergeben @RadhiRasho hat das heute übernommen. Offenstate:needs triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 61/100
zed-industries/zed#65300 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
Maintainer antworten meist innerhalb von 1 Tag