实践类型系统 (PTS) 中的错误处理

基本原则

PTS 中的一个关键原则是将两种类型的错误区分开

• *可预期* 错误，例如 file_not_found_error、network_connection_error 等。

  这些错误预计可能在运行时发生。

• *不可预期* 错误，例如 out_of_memory_error、stack_overflow_error 等。

  这些错误预计不会在运行时发生。它们仅在发生通常无法在运行时解决的严重问题时才会发生。

这两种类型的错误处理方式不同。

*可预期* 错误遵循以下原则

• 可能在运行时失败的函数必须在其签名中声明可能会返回可预期错误。

• 函数返回的错误不能被静默忽略：它们必须在调用代码中处理，或 *显式* 忽略。

• 只有一个惯用的方法可以从函数 *返回* 错误，但有几种（良好支持的）方法可以 *处理* 函数返回的错误。

• 一组专用的运算符和语句可以简化错误处理。

*不可预期* 错误遵循以下原则

• 不可预期错误可能在程序执行期间的任何时间、源代码中的任何位置发生。但是，它们 *不被预期* 发生——它们是 *不可* 预期的，因此不在函数签名中声明。

• 默认情况下，不可预期错误由全局错误处理器处理。此处理器的内置默认实现会将错误信息（包括堆栈跟踪）写入标准操作系统 err 设备，然后以退出代码 1 中止程序执行。

  应用程序可以注册不同的错误处理器来定制不可预期错误的全局处理。

• 不可预期错误可以在源代码中的任何位置显式捕获，以便在特定情况下提供定制的错误处理。

• 不可预期错误通常是隐式抛出的，但也可以显式抛出，例如在运行时检测到不可恢复的问题时。

这些是基本的设计原则。

现在让我们看看细节。

Types

type error
    inherit: non_null                                                         (1)
    child_types: anticipated_error, unanticipated_error                       (2)
    factories: none                                                           (3)

    atts
        message string                                                        (4)
        id string (pattern = "[a-zA-Z0-9_-\.]{1,100}") or null default:null   (5)
        time date_time or null default:date_time.now                          (6)
        cause error or null default:null                                      (7)
    .
.

type file_error

    inherit: IO_error

    att file_path file_path

    // Get the name of the file, without it's directory
    fn file_name -> file_name
        return file_path.name
    .
.

type file_not_found_error
    inherit file_error
.

type file_read_error
    inherit file_error
.

type file_write_error
    inherit file_error
.

可预期错误

如果一个函数被宣传为在遇到困难时返回错误代码，那么你必须检查该代码，是的，即使检查会使你的代码大小加倍并使你的打字手指疼痛，因为如果你认为“这不会发生在我身上”，那么神灵一定会惩罚你的傲慢。

—— Henry Spencer，《C 程序员十诫》

在本节中，我们将探讨 *可预期* 错误——即，*可能* 在运行时发生的错误（例如，file_not_found_error、user_input_error 等）。

《基本原则》部分提到

• 可能在运行时失败的函数必须在其签名中声明可能会返回可预期错误。

• 函数返回的错误不能被静默忽略：它们必须在调用代码中处理，或 *显式* 忽略。

接下来的几节将解释 PTS 如何确保这些条件。

fn read_text_file ( file_path ) -> string
    // body
.

fn read_text_file ( file_path ) -> string or file_read_error
    // body
.

fn read_text_file ( file_path ) -> string or null or file_read_error
    // body
.

fn ask_title -> string or user_input_error

    case type of GUI_dialogs.ask_string ( prompt = "Please enter a title" )
        is string as title
            return title
        is null
            return user_input_error.create (
                message = "A title is required."
                id = "INVALID_TITLE" )
    .
.

case type of read_text_file ( file_path.create ( "example.txt" ) )
    is string as text // the string is stored in constant 'text'
        write_line ( "Content of file:" )
        write_line ( text ) // the previously defined constant 'text' is now used
    is null
        write_line ( "The file is empty." )
    is file_error as error
        write_line ( """The following error occurred: {{error.message}}""" )
.

const message = case type of read_text_file ( file_path.create ( "example.txt" ) )
    is string: "a string"
    is null: "null"
    is error: "an error"
write_line ( "The result is " + message )        

const phone_number = get_employee()?null?error \
    .get_department()?null?error \
    .get_manager()?null?error \
    .get_phone_number()

assert result is not error

const value = get_value_or_null_or_error() \
    on null : return null \
    on error as e : return e

const value = get_value_or_null_or_error() ^null ^error

fn customer_name_by_id ( id string ) -> string or inexistant_customer_error

type inexistant_customer_error
    
    inherit invalid_data_error

    att customer_id string
.

fn customer_name_by_id ( id string ) -> string or inexistant_customer_error

    // dummy implementation
    if id =v "100"
        return "Foo"
    else
        return inexistant_customer_error.create (
            message = """Customer '{{id}}' doesn't exist."""
            customer_id = id )
    .
.

fn write_customer_name ( customer_id string )

fn write_customer_name ( customer_id string )
    
    const name = customer_name_by_id ( customer_id )
    write_line ( name )
.

fn write_customer_name ( customer_id string )

    case type of customer_name_by_id ( customer_id )
        is string as name
            write_line ( name )
        is inexistant_customer_error
            write_line ( "Unknown customer" )
    .
.

fn write_customer_name ( customer_id string )

    const result = customer_name_by_id ( customer_id )
    if result is string then
        write_line ( result )
    else
        write_line ( "Unknown customer" )
    .
.

fn write_customer_name ( customer_id string )

    const name = customer_name_by_id ( customer_id ) if_is error: "Unknown customer"
    write_line ( name )
.

fn write_customer_name ( customer_id string )

    write_line ( customer_name_by_id ( customer_id ) if_is error: "Unknown customer" )
.

fn write_customer_name ( customer_id string ) -> inexistant_customer_error or null

    case type of customer_name_by_id ( customer_id )
        is string as name
            write_line ( name )
            return null
        is inexistant_customer_error as error
            return error
    .
.

fn write_customer_name ( customer_id string ) -> inexistant_customer_error or null

    const name = customer_name_by_id ( customer_id ) on error as e: return e
    write_line ( name )
.

fn write_customer_name ( customer_id string ) -> inexistant_customer_error or null

    const name = customer_name_by_id ( customer_id ) ^error
    write_line ( name )
.

fn write_customer_name ( customer_id string ) -> runtime_error or null

    case type of customer_name_by_id ( customer_id )
        is string as name
            write_line ( name )
            return null
        is inexistant_customer_error as error
            return runtime_error.create (
                message = "An error occurred."
                cause = error // can be left off for security reasons
            )
    .
.

fn write_customer_name ( customer_id string ) -> runtime_error or null

    const name = customer_name_by_id ( customer_id ) \
        on error as e: return runtime_error.create (
            "An error occurred."
            cause = e )

    write_line ( name )
.

fn write_customer_name_or_throw ( customer_id string )

    case type of customer_name_by_id ( customer_id )
        is string as name
            write_line ( name )
        is inexistant_customer_error as e
            throw program_error.create (
                message = e.message
                cause = e )
    .
.

fn write_customer_name_or_throw ( customer_id string )

    const name = customer_name_by_id ( customer_id ) \
        on error as e: throw program_error.create (
            message = e.message
            cause = e )

    write_line ( name )
.

fn write_customer_name_or_throw ( customer_id string )

    const name = customer_name_by_id ( customer_id ) \
        on error: throw

    write_line ( name )
.

fn write_customer_name ( customer_id string )

    const result = customer_name_by_id ( customer_id )
    assert result is not error
    write_line ( result ) // result is guaranteed to be a string
.

fn write_customer_name ( customer_id string )

    case type of customer_name_by_id ( customer_id )
        is string as name
            write_line ( name )
        is inexistant_customer_error
            write_line ( "Error: invalid customer id." )
            OS_process.exit ( 1 )
    .
.

fn write_customer_name ( customer_id string )

    case type of customer_name_by_id ( customer_id )
        is string as name
            write_line ( name )
        is inexistant_customer_error
            do nothing
    .
.

fn do_stuff -> stuff_error or null

    task_1() on task_error as e: return stuff_error.create (
        message = "An error occurred",
        cause = e )
    task_2()
    task_3() on task_error as e: return stuff_error.create (
        message = "An error occurred",
        cause = e )
    task_4() on task_error as e: return stuff_error.create (
        message = "An error occurred",
        cause = e )
.

fn do_stuff -> stuff_error or null

    try
        try! task_1()
        task_2()
        try! task_3()
        try! task_4()
    
    on task_error as e
        return stuff_error.create (
            message = "An error occurred",
            cause = e )
    .
.

不可预期错误

一个 *不可预期错误* 是一个 *不被预期在运行时发生* 的错误。当程序执行期间发生严重问题时，会发生不可预期错误——一个在正常情况下不应发生的问题：例如，硬件故障、操作系统问题、配置问题（例如，缺少库）、代码错误。这些错误可能在程序执行期间的任何时间、源代码中的任何位置发生。

它们通常由于软件中的错误而发生。例如

• 过深嵌套的递归函数调用（或编译器未检测到的无限递归）导致 stack_overflow_error

• 一个创建新内存对象的无限循环导致 out_of_memory_error

• 违反 assert 语句中指定的条件会导致 assert_violation_error（program_error 的子类型）

• 违反函数输入参数的前置条件会导致 pre_condition_violation_error（也是 program_error 的子类型）

• 函数中的错误可能导致 post_condition_violation_error（同样，是 program_error 的子类型）

type unanticipated_error_handler

    fn handle_error ( error unanticipated_error )
.

fn do_stuff -> stuff_error or null

    try
        try! task_1()
        task_2()
        try! task_3()
        try! task_4()
    
    on task_error as e
        return stuff_error.create (
            message = "An error occurred",
            cause = e )
    .
.

try
    do_this()
    do_that()
catch unanticipated_error as e
    // handle the error stored in constant 'e'
finally
    // clean up (e.g. close resources)
.

try
    do_this()
    do_that()
    try! task_1()
    task_2()
    try! task_3()
    try! task_4()
on anticipated_error as e
    // handle anticipated errors
catch unanticipated_error as e
    // handle unanticipated errors
finally
    // clean up
.

"throw" <expression>

if third_party_libraries_missing then
    throw program_error.create (
        message = "Third-party libraries must be installed before using this application." )
.

避免返回多种可预期错误类型！

考虑一个名为 do_stuff 的高级函数，它调用低级函数，这些函数在文件和目录上执行各种读/写操作。调用树中的这些低级函数返回可预期的错误，如 file_not_found_error、file_read_error、file_write_error、directory_read_error、directory_access_error。如果树中的每个函数都将错误传播给其父函数，那么 do_stuff 的签名可能会非常糟糕，如下所示

fn do_stuff -> string or \
    file_not_found_error or file_read_error or file_write_error or \
    directory_read_error or directory_access_error

更糟糕的是，每次调用树中的低级函数签名稍后更改时（例如，添加或删除错误类型），所有父函数的签名（包括 do_stuff）都需要相应地调整。

虽然有不同的解决方案可以避免这种维护噩梦，但对于高级函数来说，一个简单的解决方案是只返回调用树中返回的所有错误的通用父类型。例如，do_stuff 可以简化为如下

fn do_stuff -> string or directory_or_file_error

这里，我们假设 directory_or_file_error 是调用树中返回的所有错误的父类型。

现在假设，稍后在代码中添加了数据库和网络操作。do_stuff 需要调整

fn do_stuff -> string or directory_or_file_error or database_error or network_error

但是，我们同样可以通过使用通用父类型来简化

fn do_stuff -> string or IO_error

实际上，从一开始就使用合适的父类型（例如 IO_error）通常是一个可接受的解决方案，因为

• 它便于代码维护。

• 调用函数通常不关心 *哪个* 错误发生了——它们只关心是否发生了错误。

• 它隐藏了实现细节，这些细节是不相关的，并且可能在未来的版本中更改。

重要的是要注意，如果调用树中的一个高级函数返回一个更高级别的错误类型，错误信息就不会丢失。例如，如果一个低级函数返回 file_not_found_error，那么声明返回 IO_error 的一个更高级别的函数仍然返回 file_not_found_error 的一个实例（即 IO_error 的子类型），该实例可以被父函数检查，或用于调试/诊断目的。

经验法则（如果理由充分，可以忽略）是，函数不应返回多种错误类型。通常，声明一个单一的错误类型，它是调用树中返回的所有错误的通用父类型，这是合适的。这导致更简单、更易于维护的代码。

在合适的情况下使用包装器！

对于前面部分中解释的“返回太多错误类型”的问题，还有另一种解决方案：定义一个专用的错误类型作为所有低级错误的包装器，并在所有低级函数中返回此包装器。

在我们的例子中，我们可以定义类型 stuff_error，它是调用树中所有错误的包装器

type stuff_error
    inherit: runtime_error
.

do_stuff 的签名变为

fn do_stuff -> string or stuff_error

低级函数也返回 stuff_error，它们将源错误（原因）存储在 cause 属性中

fn stuff_child -> null or stuff_error
    ...
    const text = read_text_file ( file_path ) \
        on file_read_error as e: return stuff_error.create (
            message = e.message
            cause = e )
    ...
.

为了缩短代码，我们可以为 stuff_error 定义一个创建者/构造函数 create_from_cause（此处未显示），然后只需编写

const text = read_text_file ( file_path ) \
    on file_read_error as e: return stuff_error.create_from_cause ( e )

同样，低级错误信息也不会丢失，因为它存储在 stuff_error 的 cause 属性中。

另请参阅：返回包装错误 部分。

在合适的情况下使用不可预期错误！

有时，我们不想处理错误——我们假设代码将在不会发生运行时错误的环境中运行。如果尽管我们的假设还是发生了错误，那么立即终止是合适的：应用程序将错误消息写入 STDERR，然后以退出代码 1 退出。

换句话说，我们选择 *中止* 执行而不是 *处理* 错误。这也称为恐慌——例如，在 Rust 中，panic! 宏可用于优雅地中止应用程序并释放资源。

在各种情况下，在遇到错误时中止程序执行（即恐慌）是合理的：例如，在尝试代码、编写原型、构建个人印章库存应用程序时，或者当我们只想编写快速而粗糙的代码时。即使在设计用于处理错误 O 的应用程序中，也可能存在一些特定情况，其中立即终止是可取的，例如，以避免长期损坏数据。有关此主题的良好建议可在 The Rust Programming Language 的 要恐慌！还是不恐慌！ 章中找到。

虽然 PTS 显然不是默认设计用于中止的，但它确实提供了对“尽早崩溃”方法的支持。如果您有充分的理由，您可以*中止*（恐慌）——您只需*明确*这样做。

基本思想是将可预期错误转换为不可预期错误，每当您必须处理可预期错误时。因此，不是返回可预期错误，而是抛出不可预期错误。让我们看看不同的方法。

assert 语句

一种技术是使用 assert 语句来声明可预期错误不应该发生

const result = customer_name_by_id ( customer_id )
assert result is not error
// continue with a customer object stored in 'result'

on error: throw 子句

一种更好、更简洁的技术是使用 on error: throw 子句，该子句已在 抛出不可预期错误 部分介绍

const name = customer_name_by_id ( customer_id ) on error: throw

抛出错误的实用函数

编写大量 on error: throw 子句可能会令人讨厌。因此，更好的解决方案可能是编写抛出不可预期错误而不是返回可预期错误的实用函数。

例如，假设我们的许多代码（在快速、一次性原型中）都读取非空文本文件。在正常情况下（即，当可靠性很重要时），我们将调用一个库函数，如下所示

// returns 'null' if the file is empty
fn read_text_file ( file_path ) -> string or null or file_read_error

使用此函数需要检查 null 和 file_read_error。为了避免这些检查，我们可以定义以下实用函数，该函数假定文件读取错误不会发生，并且文本文件永远不会为空

fn read_non_empty_text_file_or_throw ( file_path ) -> string      (1)

    case type of read_text_file ( file_path )
        is string as content
            return content
        is null
            throw program_error.create (                          (2)
                """File {{path.to_string}} is empty.""" )
        is file_read_error as e
            throw program_error.create (
                """Could not read file {{path.to_string}}         (3)
                Reason: {{e.message}}""" )
    .
.

(1) 根据约定，函数名后缀 _or_throw 表示可能会抛出不可预期错误。在正常情况下，函数返回一个 string，其中包含非空文本文件的内容。

(2) 如果文件为空，则抛出不可预期错误。

(3) 如果无法读取文件，则抛出不可预期错误。

可以按如下方式编写上述函数的简化版本

fn read_non_empty_text_file_or_throw ( file_path ) -> string

    const result = read_text_file ( file_path )
    assert result is not null and result is not error
    return result
.

客户端代码现在简单快捷，因为不再需要 null 和错误处理

const text = read_non_empty_text_file_or_throw ( file_path.create ( "example.txt" ) )

在私有代码中使用不可预期错误

有时，在应用程序的未公开（私有）部分使用不可预期错误是有意义的，因为这可以大大简化代码并提高可维护性。

假设我们正在处理一个复杂的解析器，其主函数如下所示

fn parse ( string ) -> AST or syntax_error

语法错误很可能在低级、私有函数中被检测到。在函数 parse 的整个调用树中使用可预期错误很容易导致冗长 O 的代码，因为所有错误都需要处理（例如，传播给父函数）并在函数签名中声明。每当函数签名中的错误类型稍后更改时，都需要进行大量重构。为了避免这种维护负担，最好在 parse（调用树中的根函数）调用的函数中抛出不可预期错误。函数 parse 使用 try 语句来捕获任何不可预期错误，并将其转换为可预期错误，然后返回。以下简化代码说明了此方法

fn parse ( string ) -> AST or syntax_error

    try
        const AST = AST.create_empty
        // parse the string and populate 'AST'
        return AST
    catch unanticipated_error as ue
        return syntax_error.create ( message = ue.message )
    .
.

不要使用 null 返回错误条件！

假设您正在设计标准库中的 map 类型（又称 dictionary、associated_array）。方法 get 接受一个键作为输入并返回存储在 map 中的相应值。这里有一个有趣的问题：如果键不存在，该方法应该做什么？

很容易就返回 null，就像在几个库（例如 Java Map.get）中那样。使用 PTS 语法，map 可以定义如下

type map<key_type child_of:hashable, value_type>
    
    fn get ( key key_type ) -> value_type or null

    // more methods
.

这种方法有两个缺点

• 如果 map 中的值允许为 null（例如，map<string, string or null>），则会出现歧义。

  例如，如果一个方法调用像 map.get ( "foo" ) 返回 null，它可以有两种含义：要么没有键为 "foo" 的条目，要么有一个键为 "foo" 且值为 null 的条目。

• 如果 map 中的值不允许为 null（例如 map<string, string>），则存在误解的风险。

  例如，如果一个方法调用像 map.get ( "foo" ) 返回 null，它可能被客户端代码错误地解释为键为 "foo" 且值为 null 的条目。

  如果一个具有可空值的 map 后来更改为具有非空值的 map（例如，从 map<string, string or null> 到 map<string, string>），这种误解的风险会增加。

为了消除第一个问题（返回 null 时的歧义），我们可以添加方法 contains_key（反正也需要）。

type map<key_type child_of:hashable, value_type>
    
    fn contains_key ( key key_type ) -> boolean
    
    fn get ( key key_type ) -> value_type or null

    // more methods
.

这样做有效，因为我们现在可以调用 contains_key 来消除歧义。但这并不奏效。首先，方法 get 易于出错，因为必须阅读文档、小心操作，并且不能忘记在 get 返回 null 时调用 contains_key。其次，先调用 get，然后调用 contains_key，是冗长的，并且在并发或并行处理环境中共享可变 map 时可能导致非常棘手的 bug（由于竞争条件）。

如果 get 在键不在 map 中时返回错误（而不是 null），则这种易出错性会消失

type map<key_type child_of:hashable, value_type>
    
    fn get ( key key_type ) -> value_type or key_not_contained_in_map_error

    // more methods
.

客户端代码现在被要求检查 key_not_contained_in_map_error，例如。

const value = map.get ( "foo" ) on error as e: return e

我们受到了保护，不会忘记检查键是否实际存在于 map 中。此外，方法 get 可能失败的事实也在客户端代码中得到了清晰的表达。

然而，被强迫检查错误可能会令人厌烦，并导致冗长 O 的代码。如果键不在 map 中，您可能想

• 抛出一个不可预期错误，因为您假设该键应该包含在 map 中

• 回退到默认值

• 获取 null，因为您不需要区分 null 的两个可能含义

这些用例可以很容易地通过添加 get 方法的变体来覆盖

type map<key_type child_of:hashable, value_type>
    
    fn get ( key key_type ) -> value_type or key_not_contained_in_map_error
    fn get_or_throw ( key key_type ) -> value_type
    fn get_or_default ( key key_type, default value_type ) -> value_type
    fn get_or_null ( key key_type ) -> value_type or null

    // more methods
.

提供多种选择有时是适得其反的，但在这种情况下，由于 map 是一个基本数据结构，定义在标准库中，并且以多种方式使用，因此是合理的。

除了提供更通用的 API 外，我们还受益于以下几点

• 四个 getter 方法的行为由它们的签名清晰地表达——程序员可能不需要阅读文档就知道使用哪个 getter 方法（尽管他/她仍然必须意识到返回 null 的 get_or_null 的潜在模糊含义）。

• 在所有情况下，客户端代码都简洁明了，并在键不存在时自动记录行为。以下是一些示例

  const value_1 = map.get ( "foo" ) ^error
  
  const value_2 = map.get_or_throw ( "foo" )
  
  const value_3 = map.get_or_default ( key = "foo", default = "bar" )
  
  const value_4 = map.get_or_null ( "foo" )
  if value_4 is null then
      // handle it
  .