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 ""
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
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)
}
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.