Zum Hauptinhalt springen
ProdukteDesktop-WerkzeugeTASTECADZeichnungsprüfungTASTEFILESDateiverwaltungTASTEFTPDateiübertragungTASTESSHRemote-ArbeitsbereichTASTEZIPKomprimieren und EntpackenEntwicklerwerkzeugeTASTECODEIntegrierte Entwicklungsumgebung für RustTASTESTUDIOIntegrierte Entwicklungs- und TestumgebungTASTEETLDatenintegration (ETL)ServerTASTEREMOTERemote-Desktop-ServerTASTEGEOGeodatenserverTASTEMAILE-Mail-ArbeitsbereichErste SchritteDownloadsDokumentationKaufenAlle Produkte
Marktplatz
Neuigkeiten
TechnikNeuigkeitenEntwickler-News von heuteEntwicklerdokuProgrammiersprachenRustTypeScriptJavaScriptPythonGoC#JavaCC++KotlinDartWeb-Frontend-FrameworksNext.jsReactVue.js · NuxtSvelteKitAngularServer-FrameworksSpring BootDjangoFastAPIASP.NET CoreNestJS · ExpressApp- & Desktop-FrameworksTauriFlutterReact NativeElectronAlgorithmenAlgorithmus-GrundlagenKernalgorithmenFortgeschrittene AlgorithmenAlgorithmen für die Praxis
CommunityProjekteEntwicklungslogsPromptsProbleme mit KI-ToolsShowcaseCommunity-Leitfaden
ZusammenarbeitWissenstransferWebsite-AufbauDesktop-App-AufbauRelease- und ZahlungspipelineVertriebspartnerKontakt
DiensteRemote-DesktopIndividuelle Installationspakete
TASTEDEV
Produkte

Desktop-Werkzeuge

TASTECADKomplexe Zeichnungen, mühelos geöffnetTASTEFILESNur die Dateien, die zählen – in BestzeitTASTEFTPDer aufgeräumteste Weg für Ihre DateienTASTESSHDie stärkere Verbindung zu Ihren ServernTASTEZIPSchneller packen, sicherer entpacken

Entwicklerwerkzeuge

TASTECODERust-Apps bearbeiten, bauen, debuggen und testen – alles in einem FensterTASTESTUDIOVom Bearbeiten bis zu Remote-Tests und freigegebenen KI-KorrekturenTASTEETLDaten bewegen, die Werte im Blick

Server

TASTEREMOTEEin Remote-Desktop auf Ihrem eigenen ServerTASTEGEOEin GeoServer-kompatibler Geodatenserver, neu aufgebaut in RustTASTEMAILIhre E-Mail wieder in Ihrer Hand

Erste Schritte

DownloadsNeueste Versionen aller ProdukteDokuSo nutzen Sie jedes ProduktKaufenAbos und DauerlizenzenAlle ProdukteAlle Produkte im Überblick
Alle Produkte
MarktplatzNeuigkeiten
Technik

Neuigkeiten

Entwickler-News von heuteOffizielle Meldungen zu Sprachen, Frameworks, GitHub und KIEntwicklerdokuAnleitungen zu Sprachen, Frameworks und Algorithmen

Programmiersprachen

RustTypeScriptJavaScriptPythonGoC#JavaCC++KotlinDart

Frameworks

Web-Frontend-FrameworksNext.jsReactVue.js · NuxtSvelteKitAngular
Server-FrameworksSpring BootDjangoFastAPIASP.NET CoreNestJS · Express
App- & Desktop-FrameworksTauriFlutterReact NativeElectron

Algorithmen

Algorithmus-GrundlagenKomplexitätsanalyse · Sortieren · Suchen · Grundlegende Datenstrukturen · Bäume und HeapsKernalgorithmenGraphtraversierung · Kürzeste Wege und minimale Spannbäume · Dynamische Programmierung · Greedy-Algorithmen · Teile und herrsche · BacktrackingFortgeschrittene AlgorithmenZeichenkettenalgorithmen · Mathematik und Zahlentheorie · Bitmanipulation · Segmentbäume · Union-FindAlgorithmen für die PraxisStrategie für Coding-Interviews · LRU-Cache · Rate Limiting · Konsistentes Hashing
Alle Entwicklungsdokumente
Community
ProjekteEntwickler und Projekte entdeckenEntwicklungslogsEntscheidungen und ErkenntnissePromptsWiederverwendbare AnweisungenProbleme mit KI-ToolsProbleme und Workarounds für Claude, Codex, GeminiShowcaseFertige ErgebnisseCommunity-LeitfadenWie wir offen entwickeln
Zusammenarbeit
WissenstransferNative Apps mit Rust und eguiWebsite-Aufbau10 Sprachen, Konten, Dokumentation und DownloadsDesktop-App-AufbauRust und egui, ohne WebViewRelease- und ZahlungspipelineSignatur, MSI, deb, rpm, AppImage, PrüfsummenVertriebspartnerEmpfehlen und 30 % erhaltenKontaktEntwicklung, Partnerschaft, Investition
Dienste
Remote-DesktopIhren Computer im Browser erreichenIndividuelle InstallationspaketeNur nötige Funktionen, Einstellungen vorab
Kaufen
DE
한국어EnglishDeutschEspañolFrançaisItalianoPortuguês (Brasil)日本語简体中文繁體中文
Anmelden
Anmelden
TASTEDEV

Von kleinen Werkzeugen zu besserer Entwicklung.

support@tastedev.netTASTEDEV unterstützen
ProdukteProduktübersichtKaufenDokuDownloadsMarktplatzSupport
CommunityProjekteEntwicklungslogsPromptsProbleme mit KI-ToolsShowcase
RichtlinienDatenschutzerklärungNutzungsbedingungenAbo-BedingungenRückerstattungCommunity-Richtlinien
KontoAnmeldenRegistrieren
Besucher
Heute
012345678901234567890123456789012345678901234567890123456789
Gestern
012345678901234567890123456789012345678901234567890123456789
Aufrufe gesamt
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
Firma
GXSOFT
Vertretungsberechtigt
CHOI YOUNG GU
Handelsregisternummer
853-44-00368
Anschrift
9F V24, 351 Gyeongin-ro, Michuhol-gu, Incheon, Republic of Korea
Telefon
+82-10-4404-1523
E-Mail
whitecalvin@tastedev.net
Datenschutzbeauftragter
CHOI YOUNG GU

© 2026 TASTEDEVProduktinformationen basieren auf verifizierten Entwicklungsquellen.Veröffentlicht · wird verbessert

Go-Dokumentation
Go
Getting Started with GoSyntax BasicsTypes and DataModules and PackagesErrors and TestingKey Concepts: Concurrency
Diskussionen

Go-Anleitung · 5/6

Errors and Testing

Dieses Kapitel ist vorerst nur auf Englisch verfügbar.

Go has no exceptions. Errors are ordinary values that functions return and callers inspect right where the call happens. Testing is just as down to earth: the standard testing package and the go test command cover most needs without any third-party framework. This chapter covers error values, wrapping, panic and recover, and how to write tests and benchmarks.

Errors are values

error is a built-in interface with a single method, Error() string. A function that can fail returns an error as its last result, and nil means success. Callers check it immediately with if err != nil.

import (
	"errors"
	"fmt"
	"strconv"
)

var ErrEmpty = errors.New("empty input") // sentinel error, exported for comparison

func parseAge(s string) (int, error) {
	if s == "" {
		return 0, ErrEmpty
	}
	n, err := strconv.Atoi(s)
	if err != nil {
		return 0, fmt.Errorf("parse age %q: %w", s, err)
	}
	if n < 0 {
		return 0, fmt.Errorf("age cannot be negative: %d", n)
	}
	return n, nil
}

The repeated if err != nil can look noisy, but it makes every failure path visible in the code. By convention, error strings start lowercase and have no trailing punctuation, because they are often embedded inside other messages.

Wrapping with %w, errors.Is and errors.As

Using the %w verb in fmt.Errorf wraps the original error: you add context while keeping the cause reachable. To test for a specific error, use errors.Is instead of ==. To pull out an error of a particular type, use errors.As. Both walk the entire chain of wrapped errors.

type NotFoundError struct {
	ID string
}

func (e *NotFoundError) Error() string { return "not found: " + e.ID }

func load(id string) error {
	return fmt.Errorf("load: %w", &NotFoundError{ID: id})
}

func main() {
	_, err := parseAge("")
	if errors.Is(err, ErrEmpty) {
		fmt.Println("nothing to parse")
	}

	err = load("42")
	var nf *NotFoundError
	if errors.As(err, &nf) {
		fmt.Println("missing ID:", nf.ID)
	}
	fmt.Println(err) // load: not found: 42
}

Formatting an error with %v instead keeps the text but severs the link to the cause. Choose %w when callers should be able to inspect the underlying error, and %v when it is an implementation detail you would rather not commit to. To combine several errors into one, use errors.Join.

panic and recover

panic is for situations that ordinary error handling cannot sensibly deal with: programmer mistakes and states that should be impossible. The runtime itself panics on things like an out-of-range index or a write to a map. A panic unwinds the stack, running deferred calls along the way, and crashes the program if nothing stops it.

Fragen zu diesem Kapitel?
Vorheriges KapitelModules and PackagesNächstes KapitelKey Concepts: Concurrency
nil

recover only works inside a deferred function. It stops an in-progress panic and returns the value that was passed to panic. Its main legitimate use is at boundaries, for example so that one bad request does not take down an entire server.

func safeDivide(a, b int) (result int, err error) {
	defer func() {
		if r := recover(); r != nil {
			err = fmt.Errorf("recovered: %v", r)
		}
	}()
	return a / b, nil // panics at runtime when b is 0
}

func main() {
	_, err := safeDivide(1, 0)
	fmt.Println(err) // recovered: runtime error: integer divide by zero
}

Libraries should not let panics escape to their callers; return an error instead. Assigning to a named result such as err inside the deferred function is how the recovered failure gets reported back.

The testing package

Test files end in _test.go. Test functions start with Test and take a *testing.T, and go test discovers and runs them. t.Errorf records a failure and keeps going, while t.Fatalf stops the current test right away.

// file: age_test.go
package main

import (
	"errors"
	"testing"
)

func TestParseAgeEmpty(t *testing.T) {
	_, err := parseAge("")
	if !errors.Is(err, ErrEmpty) {
		t.Fatalf("want ErrEmpty, got %v", err)
	}
}

Table-driven tests

The most common Go testing style is the table-driven test: list inputs and expected outputs in a slice of structs, then loop over it. Running each case through t.Run makes it a named subtest, so failures say exactly which case broke and you can rerun just that one.

func TestParseAge(t *testing.T) {
	tests := []struct {
		name    string
		in      string
		want    int
		wantErr bool
	}{
		{"valid", "30", 30, false},
		{"not a number", "abc", 0, true},
		{"negative", "-1", 0, true},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			got, err := parseAge(tt.in)
			if (err != nil) != tt.wantErr {
				t.Fatalf("err = %v, wantErr %v", err, tt.wantErr)
			}
			if got != tt.want {
				t.Errorf("parseAge(%q) = %d, want %d", tt.in, got, tt.want)
			}
		})
	}
}

Benchmarks and running tests

Benchmark functions start with Benchmark and take a *testing.B. Put the code you want to measure inside a for b.Loop() loop and the framework decides how many iterations it needs for a stable result. Older code uses the equivalent for i := 0; i < b.N; i++ form.

func BenchmarkParseAge(b *testing.B) {
	for b.Loop() {
		parseAge("42")
	}
}
go test ./...                            # every package
go test -v -run 'TestParseAge/negative' . # one subtest, verbose
go test -race ./...                      # with the data race detector
go test -cover ./...                     # coverage summary
go test -bench . -benchmem               # benchmarks plus allocation stats

Summary

  • Return error as the last result and check if err != nil right away.
  • Wrap with fmt.Errorf("context: %w", err) and inspect with errors.Is and errors.As.
  • Reserve panic for the truly unrecoverable, and recover only at boundaries inside defer.
  • Tests are TestXxx(t *testing.T) functions in _test.go files; table-driven tests with t.Run are the norm.
  • Measure performance with BenchmarkXxx(b *testing.B) and go test -bench.

0 Kommentare

Top-KommentareNeueste zuerst

Anmelden · Melde dich an, um einen Kommentar zu schreiben.