2020-04-26 23:47:41 +03:00
|
|
|
#pragma once
|
2023-04-07 16:55:28 +03:00
|
|
|
/**
|
|
|
|
* @file
|
|
|
|
*
|
|
|
|
* @brief This file defines two main structs/classes used in nix error handling.
|
|
|
|
*
|
|
|
|
* ErrorInfo provides a standard payload of error information, with conversion to string
|
|
|
|
* happening in the logger rather than at the call site.
|
|
|
|
*
|
|
|
|
* BaseError is the ancestor of nix specific exceptions (and Interrupted), and contains
|
|
|
|
* an ErrorInfo.
|
|
|
|
*
|
|
|
|
* ErrorInfo structs are sent to the logger as part of an exception, or directly with the
|
|
|
|
* logError or logWarning macros.
|
|
|
|
* See libutil/tests/logging.cc for usage examples.
|
|
|
|
*/
|
2020-03-22 20:25:47 +02:00
|
|
|
|
2022-03-03 11:50:35 +02:00
|
|
|
#include "suggestions.hh"
|
2020-04-26 23:47:41 +03:00
|
|
|
#include "ref.hh"
|
2020-04-03 17:48:20 +03:00
|
|
|
#include "types.hh"
|
2020-07-07 15:37:47 +03:00
|
|
|
#include "fmt.hh"
|
2020-03-27 18:55:09 +02:00
|
|
|
|
2020-06-16 02:35:07 +03:00
|
|
|
#include <cstring>
|
2020-04-26 23:47:41 +03:00
|
|
|
#include <list>
|
|
|
|
#include <memory>
|
|
|
|
#include <map>
|
|
|
|
#include <optional>
|
2023-12-15 21:52:21 +02:00
|
|
|
#include <compare>
|
2020-03-22 20:25:47 +02:00
|
|
|
|
2020-07-07 15:37:47 +03:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <fcntl.h>
|
2020-03-22 20:25:47 +02:00
|
|
|
|
2020-04-26 23:47:41 +03:00
|
|
|
namespace nix {
|
|
|
|
|
2020-06-04 20:53:19 +03:00
|
|
|
|
2020-04-29 06:06:08 +03:00
|
|
|
typedef enum {
|
2020-04-26 23:47:41 +03:00
|
|
|
lvlError = 0,
|
|
|
|
lvlWarn,
|
2020-11-27 12:19:36 +02:00
|
|
|
lvlNotice,
|
2020-04-26 23:47:41 +03:00
|
|
|
lvlInfo,
|
|
|
|
lvlTalkative,
|
|
|
|
lvlChatty,
|
|
|
|
lvlDebug,
|
|
|
|
lvlVomit
|
|
|
|
} Verbosity;
|
|
|
|
|
2023-03-27 04:12:25 +03:00
|
|
|
/**
|
|
|
|
* The lines of code surrounding an error.
|
|
|
|
*/
|
2020-06-24 17:33:53 +03:00
|
|
|
struct LinesOfCode {
|
2022-02-25 17:00:00 +02:00
|
|
|
std::optional<std::string> prevLineOfCode;
|
|
|
|
std::optional<std::string> errLineOfCode;
|
|
|
|
std::optional<std::string> nextLineOfCode;
|
2020-06-24 17:33:53 +03:00
|
|
|
};
|
|
|
|
|
2023-12-18 23:14:42 +02:00
|
|
|
struct Pos;
|
2022-04-29 20:27:38 +03:00
|
|
|
|
2021-09-13 20:57:25 +03:00
|
|
|
void printCodeLines(std::ostream & out,
|
2022-04-07 22:42:01 +03:00
|
|
|
const std::string & prefix,
|
2023-12-18 23:14:42 +02:00
|
|
|
const Pos & errPos,
|
2021-09-13 20:57:25 +03:00
|
|
|
const LinesOfCode & loc);
|
|
|
|
|
2020-06-19 00:25:26 +03:00
|
|
|
struct Trace {
|
2023-12-18 23:14:42 +02:00
|
|
|
std::shared_ptr<Pos> pos;
|
2024-02-04 06:35:19 +02:00
|
|
|
HintFmt hint;
|
2023-01-19 14:23:04 +02:00
|
|
|
bool frame;
|
2020-03-24 19:21:35 +02:00
|
|
|
};
|
|
|
|
|
2023-12-15 21:52:21 +02:00
|
|
|
inline bool operator<(const Trace& lhs, const Trace& rhs);
|
|
|
|
inline bool operator> (const Trace& lhs, const Trace& rhs);
|
|
|
|
inline bool operator<=(const Trace& lhs, const Trace& rhs);
|
|
|
|
inline bool operator>=(const Trace& lhs, const Trace& rhs);
|
|
|
|
|
2020-04-29 06:06:08 +03:00
|
|
|
struct ErrorInfo {
|
2020-04-26 23:47:41 +03:00
|
|
|
Verbosity level;
|
2024-02-04 06:35:19 +02:00
|
|
|
HintFmt msg;
|
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
|
|
|
std::shared_ptr<Pos> pos;
|
2020-06-19 00:25:26 +03:00
|
|
|
std::list<Trace> traces;
|
2020-03-24 19:21:35 +02:00
|
|
|
|
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
|
|
|
/**
|
|
|
|
* Exit status.
|
|
|
|
*/
|
|
|
|
unsigned int status = 1;
|
|
|
|
|
2022-03-03 11:50:35 +02:00
|
|
|
Suggestions suggestions;
|
|
|
|
|
2022-02-25 17:00:00 +02:00
|
|
|
static std::optional<std::string> programName;
|
2020-04-07 04:43:22 +03:00
|
|
|
};
|
2020-03-24 19:21:35 +02:00
|
|
|
|
2022-02-25 17:00:00 +02:00
|
|
|
std::ostream & showErrorInfo(std::ostream & out, const ErrorInfo & einfo, bool showTrace);
|
2020-03-24 19:21:35 +02:00
|
|
|
|
2023-03-27 04:12:25 +03:00
|
|
|
/**
|
|
|
|
* BaseError should generally not be caught, as it has Interrupted as
|
|
|
|
* a subclass. Catch Error instead.
|
|
|
|
*/
|
2020-04-26 23:47:41 +03:00
|
|
|
class BaseError : public std::exception
|
2020-04-07 04:43:22 +03:00
|
|
|
{
|
2020-04-26 23:47:41 +03:00
|
|
|
protected:
|
2020-05-08 01:43:36 +03:00
|
|
|
mutable ErrorInfo err;
|
2020-04-30 03:57:05 +03:00
|
|
|
|
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
|
|
|
/**
|
|
|
|
* Cached formatted contents of `err.msg`.
|
|
|
|
*/
|
2022-02-25 17:00:00 +02:00
|
|
|
mutable std::optional<std::string> what_;
|
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
|
|
|
/**
|
|
|
|
* Format `err.msg` and set `what_` to the resulting value.
|
|
|
|
*/
|
2022-02-25 17:00:00 +02:00
|
|
|
const std::string & calcWhat() const;
|
2020-06-15 15:06:58 +03:00
|
|
|
|
2020-04-07 04:43:22 +03:00
|
|
|
public:
|
2023-01-19 14:23:04 +02:00
|
|
|
BaseError(const BaseError &) = default;
|
|
|
|
|
2020-04-26 23:47:41 +03:00
|
|
|
template<typename... Args>
|
|
|
|
BaseError(unsigned int status, const Args & ... args)
|
2024-02-04 06:35:19 +02:00
|
|
|
: err { .level = lvlError, .msg = HintFmt(args...), .status = status }
|
2020-04-30 03:57:05 +03:00
|
|
|
{ }
|
2020-04-26 23:47:41 +03:00
|
|
|
|
|
|
|
template<typename... Args>
|
2022-01-17 20:28:42 +02:00
|
|
|
explicit BaseError(const std::string & fs, const Args & ... args)
|
2024-02-04 06:35:19 +02:00
|
|
|
: err { .level = lvlError, .msg = HintFmt(fs, args...) }
|
2020-04-30 03:57:05 +03:00
|
|
|
{ }
|
2020-04-26 23:47:41 +03:00
|
|
|
|
2022-03-03 11:50:35 +02:00
|
|
|
template<typename... Args>
|
|
|
|
BaseError(const Suggestions & sug, const Args & ... args)
|
2024-02-04 06:35:19 +02:00
|
|
|
: err { .level = lvlError, .msg = HintFmt(args...), .suggestions = sug }
|
2022-03-03 11:50:35 +02:00
|
|
|
{ }
|
|
|
|
|
2024-02-04 06:35:19 +02:00
|
|
|
BaseError(HintFmt hint)
|
2021-01-21 01:27:36 +02:00
|
|
|
: err { .level = lvlError, .msg = hint }
|
2020-05-03 17:01:25 +03:00
|
|
|
{ }
|
|
|
|
|
2020-06-15 15:06:58 +03:00
|
|
|
BaseError(ErrorInfo && e)
|
|
|
|
: err(std::move(e))
|
|
|
|
{ }
|
|
|
|
|
|
|
|
BaseError(const ErrorInfo & e)
|
2020-04-26 23:47:41 +03:00
|
|
|
: err(e)
|
2020-04-30 03:57:05 +03:00
|
|
|
{ }
|
2020-04-29 06:06:08 +03:00
|
|
|
|
2020-05-08 01:43:36 +03:00
|
|
|
const char * what() const noexcept override { return calcWhat().c_str(); }
|
2022-02-25 17:00:00 +02:00
|
|
|
const std::string & msg() const { return calcWhat(); }
|
2020-10-07 17:33:19 +03:00
|
|
|
const ErrorInfo & info() const { calcWhat(); return err; }
|
2020-06-24 22:10:41 +03:00
|
|
|
|
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
|
|
|
void withExitStatus(unsigned int status)
|
|
|
|
{
|
|
|
|
err.status = status;
|
|
|
|
}
|
|
|
|
|
|
|
|
void atPos(std::shared_ptr<Pos> pos) {
|
|
|
|
err.pos = pos;
|
|
|
|
}
|
|
|
|
|
2023-01-19 14:23:04 +02:00
|
|
|
void pushTrace(Trace trace)
|
|
|
|
{
|
|
|
|
err.traces.push_front(trace);
|
|
|
|
}
|
|
|
|
|
2020-06-24 22:46:25 +03:00
|
|
|
template<typename... Args>
|
2023-12-18 23:14:42 +02:00
|
|
|
void addTrace(std::shared_ptr<Pos> && e, std::string_view fs, const Args & ... args)
|
2020-06-24 22:46:25 +03:00
|
|
|
{
|
2024-02-04 06:35:19 +02:00
|
|
|
addTrace(std::move(e), HintFmt(std::string(fs), args...));
|
2020-06-24 22:46:25 +03:00
|
|
|
}
|
|
|
|
|
2024-02-04 06:35:19 +02:00
|
|
|
void addTrace(std::shared_ptr<Pos> && e, HintFmt hint, bool frame = false);
|
2020-06-25 03:31:28 +03:00
|
|
|
|
|
|
|
bool hasTrace() const { return !err.traces.empty(); }
|
2023-01-19 14:23:04 +02:00
|
|
|
|
|
|
|
const ErrorInfo & info() { return err; };
|
2020-04-07 04:43:22 +03:00
|
|
|
};
|
|
|
|
|
2020-04-26 23:47:41 +03:00
|
|
|
#define MakeError(newClass, superClass) \
|
|
|
|
class newClass : public superClass \
|
|
|
|
{ \
|
|
|
|
public: \
|
|
|
|
using superClass::superClass; \
|
|
|
|
}
|
2020-04-08 18:07:58 +03:00
|
|
|
|
2020-04-26 23:47:41 +03:00
|
|
|
MakeError(Error, BaseError);
|
2020-06-17 11:26:52 +03:00
|
|
|
MakeError(UsageError, Error);
|
2020-07-20 21:13:37 +03:00
|
|
|
MakeError(UnimplementedError, Error);
|
2020-03-24 22:24:57 +02:00
|
|
|
|
2023-12-02 00:03:28 +02:00
|
|
|
/**
|
|
|
|
* To use in catch-blocks.
|
|
|
|
*/
|
|
|
|
MakeError(SystemError, Error);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* POSIX system error, created using `errno`, `strerror` friends.
|
|
|
|
*
|
|
|
|
* Throw this, but prefer not to catch this, and catch `SystemError`
|
|
|
|
* instead. This allows implementations to freely switch between this
|
|
|
|
* and `WinError` without breaking catch blocks.
|
|
|
|
*
|
|
|
|
* However, it is permissible to catch this and rethrow so long as
|
|
|
|
* certain conditions are not met (e.g. to catch only if `errNo =
|
|
|
|
* EFooBar`). In that case, try to also catch the equivalent `WinError`
|
|
|
|
* code.
|
|
|
|
*
|
|
|
|
* @todo Rename this to `PosixError` or similar. At this point Windows
|
|
|
|
* support is too WIP to justify the code churn, but if it is finished
|
|
|
|
* then a better identifier becomes moe worth it.
|
|
|
|
*/
|
|
|
|
class SysError : public SystemError
|
2020-04-03 01:02:40 +03:00
|
|
|
{
|
2020-04-26 23:47:41 +03:00
|
|
|
public:
|
|
|
|
int errNo;
|
2020-03-24 17:18:23 +02:00
|
|
|
|
2023-12-02 00:03:28 +02:00
|
|
|
/**
|
|
|
|
* Construct using the explicitly-provided error number. `strerror`
|
|
|
|
* will be used to try to add additional information to the message.
|
|
|
|
*/
|
2020-04-26 23:47:41 +03:00
|
|
|
template<typename... Args>
|
2023-12-02 00:03:28 +02:00
|
|
|
SysError(int errNo, const Args & ... args)
|
|
|
|
: SystemError(""), errNo(errNo)
|
2020-05-06 23:07:20 +03:00
|
|
|
{
|
2024-02-04 06:35:19 +02:00
|
|
|
auto hf = HintFmt(args...);
|
|
|
|
err.msg = HintFmt("%1%: %2%", Uncolored(hf.str()), strerror(errNo));
|
2020-05-06 23:07:20 +03:00
|
|
|
}
|
2022-07-19 13:49:33 +03:00
|
|
|
|
2023-12-02 00:03:28 +02:00
|
|
|
/**
|
|
|
|
* Construct using the ambient `errno`.
|
|
|
|
*
|
|
|
|
* Be sure to not perform another `errno`-modifying operation before
|
|
|
|
* calling this constructor!
|
|
|
|
*/
|
2022-07-19 13:49:33 +03:00
|
|
|
template<typename... Args>
|
|
|
|
SysError(const Args & ... args)
|
|
|
|
: SysError(errno, args ...)
|
|
|
|
{
|
|
|
|
}
|
2020-04-26 23:47:41 +03:00
|
|
|
};
|
2020-03-27 18:03:02 +02:00
|
|
|
|
2023-12-02 00:03:28 +02:00
|
|
|
/**
|
|
|
|
* Throw an exception for the purpose of checking that exception
|
|
|
|
* handling works; see 'initLibUtil()'.
|
2023-08-11 18:22:55 +03:00
|
|
|
*/
|
|
|
|
void throwExceptionSelfCheck();
|
|
|
|
|
2020-03-22 20:25:47 +02:00
|
|
|
}
|