[SUGGESTION] Value based exceptions (Zero-cost exceptions)

[redradist]

This feature is based on https://youtu.be/ARYP83yNAWk?t=2227
Long time ago I wrote to you an email about it, but it was lost somewhere in history of civilisation ...
Anyway, I just want to extend your idea to use value based exceptions like it is done in Rust for example with Result<,> class and ? syntax
See the code:

run: (file: &std::string) -> int32_t throws Error1, Error2 {
    file := File::open(file).try;
    contents := std::string{};
    file.read_to_string(contents&).try;
    return contents.trim().parse().try;
}

This function could throw 2 exceptions Error1 or Error2.
Implementation could be done using union and value for describing type of error.
See godbolt possible underlying implementation: https://godbolt.org/z/a_vbNw

I suggest to convert all functions without throws keyword ( in cpp2 syntax) to function with noexcept (in C++ current syntax)

Also a list of exceptions could be generated automatically by analyzing which new cpp2 syntax functions is called from current context:

run: (file: &std::string) -> int32_t throws {
    file := File::open(file).try;
    contents := std::string{};
    file.read_to_string(contents&).try;
    return contents.trim().parse().try;
}

could be converted to:

run: (file: &std::string) -> int32_t throws Error1, Error2 {
    file := File::open(file).try;
    contents := std::string{};
    file.read_to_string(contents&).try;
    return contents.trim().parse().try;
}

Because cpp2 compiler knows that , for example, File::open(file).try and file.read_to_string(contents&).try could throw Error1 or Error2

[switch-blade-stuff]

To add to this, it could be implemented via std::expected<T, std::error_code>.
std::expected is C++23, but is very easy to backport if necessary.

[redradist]

@switch-blade-stuff

To add to this, it could be implemented via std::expected<T, std::error_code>. std::expected is C++23, but is very easy to backport if necessary.

Completely agree, std::expected<T, std::error_code> is very similar to Result<,> in Rust

[fluffinity]

Also a list of exceptions could be generated automatically by analyzing which new cpp2 syntax functions is called from current context:

I do not think we want this behavior. The kinds of errors a function can throw should be considered part of its contract. So if we go with the current example every time the try operator gets used the error can only be Error1 or Error2 but not Error3. This way the possible errors become visible at the signature level making not only reasoning about functions as a programmer easier but tools can also handle them easier as the do not have to scan the body in order to obtain this information.

In the case of functions provided by external dynamic libraries this is actually the only way to know which error values can even be thrown as the function body may not be available at compile time. They may not be here in cpp2 now but have to be considered for this feature.

[JohelEGP]

I think I remember a speaker mentioning otherwise, just like C++1 moved away from throws. I think they also mentioned how new languages don't go down that path. Do you have proof against that?

[fluffinity]

Rust essentially makes exactly this with its Result<T, E> type. The second type argument E encodes the error type that can be returned from the function so the function can only return errors of this type E.

[JohelEGP]

Right, it remains in the signature. I think I got confused with how throws originally worked. So OP is suggesting repurposing it for a C++2 with built-in support for value-based exceptions.

[fluffinity]

Exactly.

[redradist]

@JohelEGP

I think I remember a speaker mentioning otherwise, just like C++1 moved away from throws. I think they also mentioned how new languages don't go down that path. Do you have proof against that?

Original throws was not deduced from context, but original idea was not bad, because it shows all exceptions.
I suggest to return throws keyword with potential manual list of exceptions, but the most powerfully this feature would be in case of compiler deduction, for example:

run: (file: &std::string) -> int32_t throws {
    file := File::open(file).try;
    contents := std::string{};
    file.read_to_string(contents&).try;
    return contents.trim().parse().try;
}

compiler could deduce that run throws only Error1 and Error2 and add additional mangling to signature like run_std::string_Error1_Error2 (pseudo-mangling)
I think the original feature with list of exceptions is good, but if list of exceptions is deduced by compiler using the signature

[fluffinity]

@redradist

Original throws was not deduced from context, but original idea was not bad, because it shows all exceptions.
I suggest to return throws keyword with potential manual list of exceptions, but the most powerfully this feature would be in case of compiler deduction, for example:

I do not think it is good to allow for this deduction by default for the reasons I have given in this comment. However it would be possible to use this deduction logic to offer a tool that generates the throws exception list for you. Such a tool would make migrations to cpp2 code easier while still having explicit exception lists.

[hsutter]

Specifically about listing/deducing the exceptions that can be thrown:

@redradist Here's one brain dump of the issues: https://herbsutter.com/2007/01/24/questions-about-exception-specifications/

Probably the most fundamental issue is that listing a specific set of exceptions is not composable... here are two main aspects of that:

1. It's brittle: It always exposes implementation detail, and does it virally (e.g., what if you change your implementation to call a different function that has a different exception specification), which makes code brittle. This is a major reason why Java programs generally disable checked exceptions with throws Exception, even before Java got generics.
2. It's nongeneric: With generics it's even harder, because what exception specification do you write on myfunc<T>? The answer would be to immediately invent a throws() expression to get access to the things that could be thrown, and have myfunc<T> declared as throws ( /*...?...*/ ) where "?" contains every expression its body could transitively call using a T object. Which of course also immediately exposes implementation detail and has all the problems of (1) above plus requires a lot of ugly boilerplate.

Note that (1) is still true even if the specification is deduced by the compiler (which also only works if you have the full source code for the entire call tree, which we won't always have and is another reason it's not composable).

AIUI the languages that chose to list exceptions have either backed off and deprecated/removed that feature or else have had their users de facto disable it in practice (e.g., Java throws Exception). But my information may be dated... if anyone knows of large-scale experience with listed exceptions/errors in a function interface, including for generic functions, please reply here with an example showing its use at scale in a composable way. Thanks!

[JohelEGP]

FYI, @redradist, the proposal linked at https://github.com/hsutter/cppfront#2019-zero-overhead-deterministic-exceptions-throwing-values, IIRC, allows for value-based exceptions of arbitrary load with a single type.

[redradist]

@hsutter

Specifically about listing/deducing the exceptions that can be thrown:

@redradist Here's one brain dump of the issues: https://herbsutter.com/2007/01/24/questions-about-exception-specifications/

Probably the most fundamental issue is that listing a specific set of exceptions is not composable... here are two main aspects of that:

1. It's brittle: It always exposes implementation detail, and does it virally (e.g., what if you change your implementation to call a different function that has a different exception specification), which makes code brittle. This is a major reason why Java programs generally disable checked exceptions with `throws Exception`, even before Java got generics.

I partially agree with that, but in Java the issue was that list of exceptions should be updated manually.
I think that to fix this problem we just need to allow compiler to add list of exceptions as part or signature (mangling), and if user will use a new exception that previous code should be just recompiled without manual modification of list exceptions

Note that (1) is still true even if the specification is deduced by the compiler (which also only works if you have the full source code for the entire call tree, which we won't always have and is another reason it's not composable).

No, it is possible if list of exceptions would be a part of signature run_std::string_Error1_Error2 (pseudo-mangling)

AIUI the languages that chose to list exceptions have either backed off and deprecated/removed that feature or else have had their users de facto disable it in practice (e.g., Java throws Exception). But my information may be dated... if anyone knows of large-scale experience with listed exceptions/errors in a function interface, including for generic functions, please reply here with an example showing its use at scale in a composable way. Thanks!

Okay, one additional idea, throws could mean a max size of error that could be stored on stack, see example:

main: void = {
    run("Example string");
}

run: (file: &std::string) -> int32_t throws {
    file := File::open(file).try;
    contents := std::string{};
    file.read_to_string(contents&).try;
    return contents.trim().parse().try;
}

will be converted to:

main: void = {
    error_buf: std::array<uint8_t, 2035>= {};
    run("Example string", error_buf);
}

run: (file: &std::string, error_buf: &std::array<uint8_t, 2035>) -> int32_t {
    file := File::open(file).try;
    contents := std::string{};
    file.read_to_string(contents&).try;
    return contents.trim().parse().try;
}

An error would be stored in error_buf without exposing the implementation details

[fluffinity]

@redradist

No, it is possible if list of exceptions would be a part of signature run_std::string_Error1_Error2 (pseudo-mangling)

This will not work with extern functions. The moment you change the exception list you change the symbol name and so we run into the problem that code compiled with a header file or module file of an old version of the function will not work when given a newer version of the function. For example:

run: (file: &std::string) -> int32_t throws Error1, Error2;

becomes run_std::string_Error1_Error2. Now if a newer version of the library comes out and gets shipped with the following version of the function:

run: (file: &std::string) -> int32_t throws Error2, Error1;

This function would become run_std::string_Error2_Error1. The symbol names are different and so we run into an ABI problem. From an API perspective both versions of run should be identical as their signature only differs in the order of exception declarations. Even if the order stays the same it is sufficient to add/remove exceptions from the list to break code.

Okay, one additional idea, throws could mean a max size of error that could be stored on stack, see example:

This does not solve the fundamental issue of this approach as you still need information about the exception types for a function. Again, if the source code is not available, you can not perform this analysis. Even if it is you need to re-compile your code if somewhere in the call chain an exception type changes. For example if deep in the call tree of file.read_to_string(contents&) an exception type gets changed the analysis has to be re-done if every function in the chain relies on this implicit exception list. And this would be a likely scenario because these implicit lists are easier to write than the explicit ones so people have to do extra work just to make their code robust against internal changes.

[fluffinity]

Going back to std::expected should work the best although instead of always using std::expected<T, std::error_code> std::expected<T, E> should be the default. This allows for returning arbitrary error information. For example, if we had the code:

send_string: (in s: std::string) -> std::expected<size_t, send_error<std::string>>;

In case send_string fails a general exception type allows for transferring back the string so we can continue using it. The string would only get consumed fully if the function succeeds. std::error_code is too low level for such operations.