Uniform error handling

[marekmaskarinec]

Umka has no built-in error-handling functionality (except error). I don't mind that - some languages are designed this way. However, I'm missing a uniform way of handling errors used by Umka programs and libraries. For example, tophat and Umka's standard modules don't handle errors (if you don't count returning null). On the other hand libraries like tar, os, or http handle errors in their incompatible way. Naturally, a problem will arise: what if I'd want to use two of those libraries at once in a function, and return an error from said function?

That's why I think there should be some kind of Umka error system. In my opinion implemented as part of either std.um or err.um, not as a standalone package. Here's what I want from this system:

• optional stack traces
• error stringification (however errors are not specified by a string, rather an enum)

[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.

[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]

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.