Error handling discussion

[Alihusejn]

Please do not turn Odin into second Go. Add Try/Except(or Catch). I think that Odin will become more popular than now.

[kiljacken]

How does not having exceptions make Odin into Go?

While I do agree that the Go way of handling errors is less than optimal, as it tends to produce a lot of duplicated error handling code, I beleive it is far superior to exceptions. My ideal error handling is the use of a "Result" type representing either the value of a computation if succesful, or an error message/object if not succesful (like the method commonly used in Rust). I've been out of the loop on Odin for a bit, so I am not sure if Odin has the facilities for such a type.

[ThisDevDane]

Run-time exceptions are a higher-level construct that does not fit into the vision of Odin. Also, adding a feature just because it would make Odin more popular is a terrible reason. If we just added for popularity we would also for example have GC.
But Odin is a low-level pragmatic language, so features have to been seen to add enough value for it to make it in. Adding exceptions added a huge overhead not only to the runtime, but also mentally as you can never be too sure of what exceptions any code will cast, where as return codes you can always see as the function explicitly returns it.
Plus, being a second (but better) Go isn't the end of the world, Bill has drawn a lot of inspiration from Go and I personally really like Go for what it was made for, Web Servers.

[ThisDevDane]

@kiljacken There isn't anything in Odin defining the error handling, that's still up to the individual programmer.

[misyltoad]

God no.

[bullno1]

My suggestion is that if there is something builtin for error handling, it should just be purely syntactic sugar.

In C, usually I have a macro called SOMETHING_CHECK e.g: GFX_CHECK and call it like: SOMETHING_CHECK(call_that_may_fail(...)) and it works fine albeit, a bit verbose but still better than the Go way of copy and paste that if statement.

A macro/metaprogramming system or even a specific error handler system could alleviate the problem. For example (made up syntax):

with my_error_handler {
   a := call_that_can_fail();
   b := another_call(a);
}

And it will be rewritten into:

my_error_handler(a, call_that_can_fail());
my_error_handler(b, another_call(a));

my_error_handler can then be a macro that check the return value, decides to whether return early or continue with execution.

Some type guard/check might be needed so that you can use two handlers in the same with statement for example.

This is basically the idea of Haskell's monad but modified for an imperative language. This is explicit (with block) and incurs no extra cost if you already do that anyway manually. Nothing about the runtime or function signature will change.

[luciusmagn]

I suggest taking a look at the way Rust handles errors. It is eloquent, integrated into the type system and makes the user constantly aware of what can go wrong.

…

On Mon, Sep 3, 2018 at 9:22 AM Bach Le ***@***.***> wrote: I've been lurking for quite a while, my suggestion is that if there is something builtin for error handling, it should just be purely syntactic sugar. In C, usually I have a macro called SOMETHING_CHECK e.g: GFX_CHECK and call it like: SOMETHING_CHECK(call_that_may_fail(...)) and it works fine albeit, a bit verbose but still better than the Go way of copy and paste that if statement. A macro/metaprogramming system or even a specific error handler system could alleviate the problem. For example (made up syntax): with my_error_handler { a := call_that_can_fail(); b := another_call(a); } And it will be rewritten into: my_error_handler(a, call_that_can_fail()); my_error_handler(b, another_call(a)); my_error_handler can then be a macro that check the return type, decides to whether return early or continue with execution. Some type guard/check might be needed so that you can use two handlers in the same with statement for example. This is basically the idea of Haskell's monad but modified for an imperative language. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#256 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIAzh0GJH-SR88rntADpQKPIYOKFusHyks5uXNisgaJpZM4WWvSC> .

[ThisDevDane]

@bullno1 Odin has the option for multiple return values so how would that system know which of the parameters to use for it's checking? + some function might use different values for error codes, ints, enums, bools etc..

[gingerBill]

There will never be software exceptions in the traditional sense. I hate the entire philosophy behind the concept.

Go does have exceptions with the defer, panic, recover approach. They are weird on purpose. Odin could have something similar for exceptional cases.

You can the exact same semantics as a try except block by using a switch in statement. The same is true in Go. The difference is that the stack does not need to be unwinded and it's structural control flow.

Odin has discriminated unions, enums, bit sets, distinct type definitions, any type, and more. Odin also have multiple return values. Use the type system to your advantage.

I do hate how most languages handle "errors". Treat errors like any other piece of code. Handle errors there and then and don't pass them up the stack. You make your mess; you clean it.

[dotbmp]

I get the feeling that most people in this discussion have a fairly surface-level knowledge of Odin's syntax. This isn't an insult, I'm just saying there is far less of a problem than some of you seem to think. Odin has multiple returns as well as a declaration & condition variant of if, meaning that it's a trivial matter to return a bool to indicate whether a procedure call was successful or not along with the payload return, as well as returning custom error types.

if bytes, ok := os.read_entire_file("filename.ext"); ok {
    fmt.println(string(bytes));
}
else {
    // handle failure
}

// you can also ignore returns

bytes, _ := os.read_entire_file("filename.ext"); // `_` is a value-sink; anything written to it vanishes, it cannot be read from

You can also use types like this:

Error :: struct {
     message: string,
     code: int,
}

or this:

Error_Code :: enum {
    FILE_NOT_FOUND,
    OUT_OF_MEMORY,
    COMPUTER_HATES_YOU,
}

as return values.

This is a powerful approach and gives the programmer total control of how to handle errors, as well as making the potential for an error to occur completely explicit in a procedure's prototype. Anything more than this - involving error handlers, runtime exceptions and/or try/catch - serves to take back control from the programmer and make the presence of errors a complete mystery. It makes code less readable and, in fact, more error-prone. The only "positive," if you can call it that, is that it "hides" error-handling and allows the programmer to program as though errors don't exist, passing on responsibility from libraries or worse, crashing a user's program unnecessarily. This is just laziness, as far as I can see (and you can be lazy explicitly with _ 😛).

There are numerous ways to "manufacture" your own error-handling system in Odin - Bill mentioned the tagged unions, which can be nil, and a number of other language features. There's no good reason to add something like exceptions to the base language just to save a little bit of typing and a little bit of brainpower at the expense of robust code, when you can literally accomplish the exact same effect with return types or global/thread-local variables. Getting familiar with Odin reveals a lot about why it does or doesn't have certain features, and how sometimes the lack of a feature actually is a feature in the sense that it solves the underlying problem in a better or more elegant way.

[gingerBill]

To expand on what I mean by this statement:

You can the exact same semantics as a try except block by using a switch in statement.

Python:

try:
	x = foo()
except ValueError as e:
	pass # Handle error
except BarError as e:
	pass # Handle error
except (BazError, PlopError) as e:
	pass # Handle errors

Odin:

Error :: union {
	ValueError,
	BarError,
	BazError,
	PlopError,
}

foo :: proc() -> (Value_Type, Error) { ... }

x, err := foo();
switch e in err {
case ValueError:
	// Handle error
case BarError:
	// Handle error
case BazError, PlopError:
	// Handle errors
}

The semantics are very similar in this case however the control flow is completely different. In the exceptions case (shown with Python), you enclose a block of code and catch any exceptions that have been raised. In the return value case (shown with Odin), you test the return value explicitly from the call.
Exceptions require unwinding the stack; this is much slower when an exception happens compared to the fixed small cost of a return value.

In both cases, a "catch all" is possible:
Python

try:
	x = foo()
except Exception:
	pass # An error has happened

Odin:

x, err := foo();
if err != nil {
	// An error has happened
}

One "advantage" many people like with exceptions is the ability to catch any error from a block of code:

try:
	x = foo()
	y = bar(x)
	z = baz(y)
except SomeError as e:
	pass

I personally see this as a huge vice, rather than a virtue. From reading the code, you cannot know where the error comes from. Return values are explicit about this and you know exactly what and where has caused the error.

One of the consequences of exceptions is that errors can be raised anywhere and caught anywhere. This means that the culture of pass the error up the stack for "someone else" to handle. I hate this culture and I do not want to encourage it at the language level. Handle errors there and then and don't pass them up the stack. You make your mess; you clean it.

Go's built-in error type has the exact same tendency of people return errors up the stack:

if err != nil {
	return nil, err
}

From what I have read, most people's complaints about the Go error handling system is the if err != nil, and not the return nil, err aspect. Another complain people have is that this idiom is repeated a lot, that the Go team think it is necessary to add a construct to the language reduce typing in the draft Go 2 proposal.

---

I hope this has cleared up a lot of the questions regarding Odin's take on error handling. I think error handling ought to be treated like any other piece of code.

With many rules, there will be unexpected emergent behaviour.

P.S. If you really want "exceptions", you can longjmp until the cows come home.

[kevin-neel-oracle-com]

My case is indeed similar to one you give:

try:
x = foo()
y = bar(x)
z = baz(y)
except SomeError as e:
pass

To this point: "Handle errors there and then and don't pass them up the stack. You make your mess; you clean it."

This is certainly a reasonable strategy in many programs. But I don't think it applies universally. In large systems (like database systems) responding to user input with limited resources, a dynamic environment, etc, errors aren't usually the "fault" of the upper layers (or even really a fault of the lower layers). They are most commonly:

1. user requests exceeding user-specific resource limits, causing the request to be terminated
2. system-wide limits being exceeded
3. planned maintenance operations interrupting user requests (specifically, user requests that fail to heed warnings that they should move their work elsewhere)
4. user requests outside of supported functionality (and without solving the halting problem, we can't always know this in advance)
5. bugs in other sections of the code that still must be handled gracefully by upper levels
6. administrator decides to kill some long-running operation
7. and so on

And mind you, we don't write the user requests. We are a generic request-response system. The customer (or their third party vendor) sends these requests. So we can't "fix" them.

As for the various layers of our system: many pieces of code are inner nodes in the code tree that split their piece of the work into smaller pieces. And usually:

a. all of the above errors can happen at any point in the processing
b. at any one level, response to those errors is exactly the same no matter whence they emanate. usually it is:
i. cleanup locally allocated resources (defer is nice for this. I do echo the question as to whether it supports longjmp), but only for non-session-fatal errors (if we're exiting, no point cleaning up one-by-one, and it can even cause cascaded issues)
ii. propagate to upper layers, so that they can do their own cleanup etc

At the very highest level, we abort the current request; optionally (based on the error/situation) abort the session; finally return the error to the user. This decision only needs to be done at that highest level; it would be redundant to do it at every level.

In this system, requiring explicit propagation for every procedure call just adds boilerplate that obscures the code rather than make it more readable/maintainable. And I have to imagine that our system is not unique in this respect.

Just one extermely simplified example, and it is farm from unique:

process_call():
inform_transaction_layer_of_pending_call()
inform_tracing_layer()
parse_call()
initiate_execution()
retrieve_data()
send_data()
send_session_state_metadata_changes()
///
optionally abort call
optionally kill session
construct_call_response_header()
send_call_response_header()
optionally kill process

Response to errors in the first seven functions is exactly the same. Errors within them affect what we do in the last five operations. But it doesn't matter which of the 7 functions (doing the bulk of the work for the vast majority of requests) had the error; it only matters WHAT the error was. Adding extra error-handling code around each of those seven functions only obscures them.

I am open to suggestions as to how to handle something like this with an error-return paradigm. I am having trouble finding a clean solution. And I worry that the suggested longjmp, if not explicitly integrated into the Odin environment, will fail to work cleanly (again, the question as to integration with things like defer).

Thansk,
Kevin

[kevin-neel-oracle-com]

I can imagine moving the latter parts of my example to a new calling function, that will check the error return from process_call(). But how do I apply a blanket rule that we propagate errors from any of our callees? If the compiler somehow knew that the last arg for each of these was an error, and could be told to propagate any errors, that could be clean enough.

But if errors aren't special in any way, how can it know this? Obviously we can't assume that ANY function call has an error as its last return. That would make it impossible to use many builtins and many libraries...

[hasenj]

Reduce the surface area of where errors can occur inside your code.

For example, if you need to open a file, and you're not sure it exists, and want to handle failure, don't structure your code such that this function is 10 levels down a call stack.

Define types that can embed "errors" and make your code work with these types.

File_Content :: struct {
    filename: string;
    content: string;
    error: IO_Error;
}

read_file :: (path: string) -> File_Content {
    .....
}

One "advantage" many people like with exceptions is the ability to catch any error from a block of code:

I don't think that's what people like about exceptions. They like about it that they can ignore error cases while writing code; for example, they can write something like this:

read_file :: (path: string) -> string {
    .....
}

if the file doesn't exist, none of your code has to worry about that! You pretend everything succeeds in most of your code, and then just dedicate a small portion of the most top level function to handle "exceptions".

In my experience this creates sloppy programs; hides errors, makes them hard to debug. It's also why a lot of error messages in a lot of program are confusing: it's because the programmer himself cannot know what the error is at the exception catch site; they best they can do is say "looks like something went wrong".

[gingerBill]

I don't think that's what people like about exceptions. They like about it that they can ignore error cases while writing code...

That is a completely separate aspect. That is still possible with a switch statement and using the default case.

[hasenj]

That is still possible with a switch statement and using the default case.

That's still explicitly checking for an error.

I mean not even checking if an error has occurred.

Say you have procedure A that calls B that calls C that calls D that calls E that calls F.

F can 'throw' an exception, but none of the other procedures in the call chain have to check for an error at all. E can be written with only the happy case in mind.

def F(...):
       # does something that can throw an exception

def E(..):
     e1(...)
     e2(...)
     e3 = F(....)  # an exception could be thrown here but we pretend it never occurs
     e4(e3) # pretend e3 is all good

def D(...):
    d1(...)
    d2 = E(....)
    d3(...)
    d4(d2)

Only A has to check if an exception was thrown from B. All the other procedures, from B all the way to E don't have to contain any error checking code.

That's what people like about exception throwing.

It's also why people complain about this in Go:

if err != nil {
    return nil, err
}

Because in Python and other languages this step is automatic, but in Go and languages without exception you have to explicitly emulate exception throwing for every call using the if err != nil snippet.

[gingerBill]

That's still explicitly checking for an error.

I dislike error propagation which is implicitly passing the error up the stack. People like being lazy, so don't give them more opportunity to be so.

It's also why people complain about this in Go

And that's why I like Go, because error handling is explicit. The issue I have is that people just return the error and pass it up the stack again.

It doesn't matter how the errors are implemented (values or exception) in the case, it's the error propagation.

[rdebath]

P.S. If you really want "exceptions", you can longjmp until the cows come home.

Does longjmp break defer?
Basically, a working setjmp/longjmp would be the only thing I'd use exceptions for. So that the error (and hopefully code location and full stack) can be saved and a generic recovery run without leaking memory or "resources".

In detail, any open database transactions are rolled back, the error info written out to a log (or saved in the database even) perhaps some global variables cleared, maybe a 'rollback_session' stored procedure gets called, sleep for a few seconds and restart. Preferably without restarting the whole process and losing details (like network connections to a client and which session needs to be rolled back!)