Esempio n. 1
0
const (
	xmlPrefix        = "<?xml"
	xmlPrefixWithBOM = "\xef\xbb\xbf<?xml"
)

type parser struct {
	ll *lexer
	d  *types.Dat
}

var (
	ParseError    = errors.NewClass("DAT Parse Error")
	XMLParseError = errors.NewClass("XML DAT Parse Error")

	lineNumberErrorKey = errors.GenSym()
	filePathErrorKey   = errors.GenSym()
)

func ErrorLineNumber(err error) int {
	v, ok := errors.GetData(err, lineNumberErrorKey).(int)
	if !ok {
		return -1
	}
	return v
}

func ErrorFilePath(err error) string {
	v, ok := errors.GetData(err, filePathErrorKey).(string)
	if !ok {
		return ""
Esempio n. 2
0
package cli

import (
	"github.com/spacemonkeygo/errors"
)

type ExitCode byte

const (
	EXIT_BADARGS      = ExitCode(1)
	EXIT_UNKNOWNPANIC = ExitCode(2)  // same code as golang uses when the process dies naturally on an unhandled panic.
	EXIT_USER         = ExitCode(3)  // grab bag for general user input errors (try to make a more specific code if possible/useful)
	EXIT_JOB          = ExitCode(10) // used to indicate a job reported a nonzero exit code (from cli commands that execute a single job).
)

var ExitCodeKey = errors.GenSym()

/*
	CLI errors are the last line: they should be formatted to be user-facing.
	The main method will convert a CLIError into a short and well-formatted
	message, and will *not* include stack traces unless the user is running
	with debug mode enabled.

	CLI errors are an appropriate wrapping for anything where we can map a
	problem onto something the user can understand and fix.  Errors that are
	a repeatr bug or unknown territory should *not* be mapped into a CLIError.
*/
var Error *errors.ErrorClass = errors.NewClass("CLIError")

/*
	Use this to set a specific error code the process should exit with
Esempio n. 3
0
Package errhttp provides some useful helpers on top of the errors package for
HTTP handling.

errhttp is a great example of how to use the errors package SetData and GetData
hierarchical methods.
*/
package errhttp

import (
	"fmt"

	"github.com/spacemonkeygo/errors"
)

var (
	statusCode = errors.GenSym()
	errorBody  = errors.GenSym()
)

// SetStatusCode returns an ErrorOption (for use in ErrorClass creation or
// error instantiation) that controls the error's HTTP status code
func SetStatusCode(code int) errors.ErrorOption {
	return errors.SetData(statusCode, code)
}

// OverrideErrorBody returns an ErrorOption (for use in ErrorClass creation or
// error instantiation) that controls the error body seen by GetErrorBody.
func OverrideErrorBody(message string) errors.ErrorOption {
	return errors.SetData(errorBody, message)
}
Esempio n. 4
0
	transport systems involved -- either the storage warehouse has
	experienced corruption, or the transport is having reliability
	issues, or, this may be an active attack (i.e. MITM).
*/
var HashMismatchError *errors.ErrorClass = WarehouseError.NewClass("HashMismatchError")

func NewHashMismatchError(expectedHash, actualHash string) *errors.Error {
	return HashMismatchError.NewWith(
		fmt.Sprintf("expected hash %q, got %q", expectedHash, actualHash),
		errors.SetData(HashExpectedKey, expectedHash),
		errors.SetData(HashActualKey, actualHash),
	).(*errors.Error)
}

// Found on `InputHashMismatchError`
var HashExpectedKey errors.DataKey = errors.GenSym()

// Found on `InputHashMismatchError`
var HashActualKey errors.DataKey = errors.GenSym()

/*
	Raised to indicate problems working on the operational theater on
	the local filesystem (e.g. permission denied to read during a `Scan`
	or permission denied or out-of-space during a write during `Materialize`).
*/
// REVIEW : I keep feeling like we need a more expressive name for this.  It's 'Arena' elsewhere, but that doesn't really feel jive here.
var MoorError *errors.ErrorClass = Error.NewClass("MoorError")

/*
	Wraps any other unknown errors just to emphasize the system that raised them;
	any well known errors should use a different type.