What are the advantages and disadvantages of encapsulated errors types like "Result"?

Question

I’m learning Rust and one of the things that made me curious is the absence of exceptions.

Unlike languages such as C#, Java, Javascript, etc., which have exceptions, in Rust this does not exist. If a function can fail and the error must be treated (what they call recoverable error), must return a value whose type is called Result (is an enumeration, but that’s beside the point).

It seems that the absence of exceptions has become fashionable. Rust and Go are two relatively new languages that do not have this idea so grounded in language.

• What are the advantages and disadvantages of types such as Result?
• In languages such as Rust, which require Result for recoverable errors and have a system such as panic! (in untraceable thesis) for unrecoverable errors, the absence of exceptions may be an obstacle?
• In languages with exceptions, the caller of a function may choose not to treat the error. But with Result it doesn’t seem possible to me implicitly. What to do in such cases? I am obliged to treat every possible error?

Answer 1

Exceptions are difficult to implement in C++ and Rust-type languages, which do not have "garbage collector" and compile for binary.

A program that uses exceptions gets a little slower, and especially the binary gets much larger, because all possible additional execution paths, which come into existence by the possibility of the exception, have to be treated.

(This was a bigger problem in 2001, it’s not so relevant anymore because C++ compilers have evolved a lot, and C++ is faster than Go with exceptions and all.)

Exceptions should be used to treat "exceptional situations" but the definition of "exceptional" is ambiguous and varies greatly depending on the context.

Failure to open a file may or may not be something exceptional, depends on what the program does.

Failure to open a network connection is exceptional? In my opinion, it is not, because the network can and will fail in many ways all the time.

Converting a string to an integer should raise an exception? It depends on the context. If it is during the Parsing of a document completed by a human, it is not possible to say that the occurrence of an error is exceptional...

When parsing a JSON, should an exception be raised in the case of invalid JSON? I think not, because it is part of the normal job of a parser to check if a document is valid.

As you said yourself, exceptions may or may not be dealt with, and then technical charges and bugs start to appear, especially when the "exception" is something perfectly expected, such as a failure in the network connection, situation that the code could never fail to deal with.

In this tune, "Result" style structures encourage more robust development, and with error handling occurring as close as possible to its origin.

In interpreted languages, like Javascript and Python, exceptions are a must because Runtime errors can occur which are bugs even, variable type with wrong name, wrong type, etc. Imagine a REST server: it is useful that an exception raised in an endpoint for a bug in the code is "captured" rather than letting it take down the entire server (the failure in an endpoint does not necessarily prevent the others from continuing to be used).

But in static languages this type of error cannot occur in Runtime. The problems that can occur in Runtime that one can imagine, have to be addressed explicitly.