Uniform error handling

[marekmaskarinec]

Uniform error handling

[marekmaskarinec]

Proposal # 1

This is approach is very similar to Go, as in it requires manual checking and returning of the errors. However, unlike in Go, the error isn't an interface, but rather an opaque struct. The examples will assume the module that implements the error handling is called err.um.

Creating an error:

err.mk("mymod.um", ERR_AN_ERROR_CONSTANT, "This is an optional message")

The module name and error number are used to distinguish errors in the program. The message is for the user/developer.
Checking if an error is an error is done by calling a method on it, which returns a bool. The library will also support wrapping errors, which will be used to keep the stack trace of the error. Handling an error would look like this:

val, e := someFunc()
if (e.isErr()) {
  return e.wrap()
}

return err.noErr()

Pros:

• few if not no edits are needed to the language itself
• simple to understand
• ignoring an error is an explicit decision

Cons:

• requires manual error checking
• requires multiple return values (which currently have some problems, perhaps I should make a separate issue)

[vtereshkov]

@marekmaskarinec Do you mean something like the error type in Go?

type error interface {
    Error() string
}

[marekmaskarinec]

Yes, something like that. However, I don't think we should just blindly copy Go.

[vtereshkov]

requires multiple return values (which currently have some problems, perhaps I should make a separate issue)

Is it #73 or #302 or something different?

[skejeton]

#73 should be higher priority I think, I very often only need just one value. Don't care that much for #302 yet.

[skejeton]

Proposal # 1

This is approach is very similar to Go, as in it requires manual checking and returning of the errors. However, unlike in Go, the error isn't an interface, but rather an opaque struct. The examples will assume the module that implements the error handling is called err.um.

Creating an error:

err.mk("mymod.um", ERR_AN_ERROR_CONSTANT, "This is an optional message")

The module name and error number are used to distinguish errors in the program. The message is for the user/developer. Checking if an error is an error is done by calling a method on it, which returns a bool. The library will also support wrapping errors, which will be used to keep the stack trace of the error. Handling an error would look like this:

val, e := someFunc()
if (e.isErr()) {
  return e.wrap()
}

return err.noErr()

Pros:

* few if not no edits are needed to the language itself

* simple to understand

* ignoring an error is an explicit decision

Cons:

* requires manual error checking

* requires multiple return values (which currently have some problems, perhaps I should make a separate issue)

Where are the error constants defined?

[skejeton]

P.S. I think for err.mk it's better to omit manually specifying the module if we have access to the stack trace at any time. Or at least, make it optional.

[vtereshkov]

@skejeton When I mentioned #73 and #302, I was just trying to guess what Marek meant by "some problems" with "multiple return values". Marek explained it and opened #329 and #330. They are not directly related to error handling (though can be useful). Both issues are now resolved.

[marekmaskarinec]

Where are the error constants defined?

They are defined by the programmer, probably in the module which produces the error.

P.S. I think for err.mk it's better to omit manually specifying the module if we have access to the stack trace at any time. Or at least, make it optional.

The point is that it doesn't need to be just the module. It's more of an id for the group of error codes.