November 06

On Saturday, 6 November 2021 at 19:36:19 UTC, Ola Fosheim Grøstad wrote:

>

On Saturday, 6 November 2021 at 19:13:11 UTC, Paulo Pinto wrote:

>

Go has exceptions, although they don't call them as such (panic/recover).

They discourage using it for regular errors, and Go programmers seem to swallow the very noice error-checking regime. Panic recover is also quite clunky and runtime dependent. Yes, I personally use it as clunky hack to emulate exceptions, but it is much less maintainable.

>

programming, and they are in the process of adding vocabulary types for improved error handling, based on the experience of those libraries.

Are they extending the language?

Have a look here,

https://blog.rust-lang.org/inside-rust/2021/07/01/What-the-error-handling-project-group-is-working-towards.html

November 08

On Friday, 5 November 2021 at 21:22:12 UTC, victoroak wrote:

>

On Friday, 5 November 2021 at 17:02:05 UTC, Atila Neves wrote:

> >
  • @safe void initialization

For what types? It doesn't compile for pointers, for instance, and I don't see why void initialising an int would be unsafe.

>
  • .init

Because?

Well, I can't answer for him but void initialization and .init makes it impossible to have any meaningful constraint on a type. And some types may depend on these constraints to maintain safety.

import std.stdio;

struct LimitedInt(int min, int max)
{
    @disable this();

    this(int number)
    {
        assert(number >= min);
        assert(number <= max);
        _number = number;
    }

    private int _number;
}

void main() @safe
{
    LimitedInt!(1, 1000) x = void;
    auto y = LimitedInt!(1, 1000).init;
    writeln(x);
    writeln(y);
}

It's @safe in this example but there's no way to enforce these constraints when you have those.

Interesting. Adding an invariant causes compilation to fail:

foo.d(27): Error: variable `foo.main.x` `void` initializers for structs with invariants are not allowed in safe functions
November 08

On Saturday, 6 November 2021 at 19:13:11 UTC, Paulo Pinto wrote:

>

On Saturday, 6 November 2021 at 11:45:18 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language

Worst line of reasoning for not having a feature is Go that refuses to add exceptions because they don't think people will do cleanup correctly, instead you are faced with 150% more error-handling code (or code that ignore errors).

Error handling in Rust also looks pretty atrocious, but I haven't written anything more than toy programs in Rust.

Go has exceptions, although they don't call them as such (panic/recover).

Rust error handling is not easy by default, however there are some helper libraries to make it easier to do rail oriented programming, and they are in the process of adding vocabulary types for improved error handling, based on the experience of those libraries.

I thought Rust error handling wasn't easy by default until they added the ? operator, at which point it became like exceptions but better.

To me that was always the issue with error handling without exceptions - how to easily just propagate it up (nearly always what one wants to do). I think they nailed it.

November 08

On Monday, 8 November 2021 at 14:08:32 UTC, Atila Neves wrote:

>

I thought Rust error handling wasn't easy by default until they added the ? operator, at which point it became like exceptions but better.

Looks like syntactical sugar to me, but I am no Rust expert. It means you now loose context, and how do you log?

>

To me that was always the issue with error handling without exceptions - how to easily just propagate it up (nearly always what one wants to do). I think they nailed it.

For simple situations maybe, but it looks like a hack, as far as I can tell from the docs.

November 09

On Monday, 8 November 2021 at 14:23:15 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 8 November 2021 at 14:08:32 UTC, Atila Neves wrote:

>

I thought Rust error handling wasn't easy by default until they added the ? operator, at which point it became like exceptions but better.

Looks like syntactical sugar to me, but I am no Rust expert. It means you now loose context, and how do you log?

It propagates the error to the caller, so you don't lose context, as the error still needs to be handled somewhere, you just don't explicitly have to return the error from your function etc. If you need to log the error at the specific location etc. then you just don't use the ? operator.

If the same mechanic existed in D then it would be something like:

Result!(int,Error) bar();

Result!(int,Error) foo(int x) {
    auto i = bar()?;

    return result(i * x);
}

void main() {
    auto r = foo(10);

    if (r.error) {
        // Error ...
    } else {
        writeln(r.value);
    }
}

Which would translate to:

Result!(int,Error) bar();

Result!(int,Error) foo(int x) {
    auto r = bar();

    if (r.error) return r;

    auto i = r.value;

    return result(i * x);
}

void main() {
    auto r = foo(10);

    if (r.error) {
        // Error ...
    } else {
        writeln(r.value);
    }
}

Of course the if statements would be using pattern matching for Ok and Error, which it does in Rust. But felt lazy.

November 09

On Tuesday, 9 November 2021 at 10:58:34 UTC, bauss wrote:

>

On Monday, 8 November 2021 at 14:23:15 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 8 November 2021 at 14:08:32 UTC, Atila Neves wrote:

>

I thought Rust error handling wasn't easy by default until they added the ? operator, at which point it became like exceptions but better.

Looks like syntactical sugar to me, but I am no Rust expert. It means you now loose context, and how do you log?

It propagates the error to the caller, so you don't lose context, as the error still needs to be handled somewhere, you just don't explicitly have to return the error from your function etc. If you need to log the error at the specific location etc. then you just don't use the ? operator.

As a library author you don't know what the application is interested in.

Anyway, they are working on retaining context, so the Rust developers apparently see this as being an issue.

If you can only use "?" in one location without loosing context that basically establishes it as being the quick hack it looks like (by reading the docs).

November 09

On Tuesday, 9 November 2021 at 11:09:07 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 9 November 2021 at 10:58:34 UTC, bauss wrote:

>

On Monday, 8 November 2021 at 14:23:15 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 8 November 2021 at 14:08:32 UTC, Atila Neves wrote:

>

I thought Rust error handling wasn't easy by default until they added the ? operator, at which point it became like exceptions but better.

Looks like syntactical sugar to me, but I am no Rust expert. It means you now loose context, and how do you log?

It propagates the error to the caller, so you don't lose context, as the error still needs to be handled somewhere, you just don't explicitly have to return the error from your function etc. If you need to log the error at the specific location etc. then you just don't use the ? operator.

As a library author you don't know what the application is interested in.

Anyway, they are working on retaining context, so the Rust developers apparently see this as being an issue.

If you can only use "?" in one location without loosing context that basically establishes it as being the quick hack it looks like (by reading the docs).

Yeah, it's definitely a quick hack. It was added to just remove the verbosity that you had otherwise.

November 09

On Monday, 8 November 2021 at 14:23:15 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 8 November 2021 at 14:08:32 UTC, Atila Neves wrote:

>

I thought Rust error handling wasn't easy by default until they added the ? operator, at which point it became like exceptions but better.

Looks like syntactical sugar to me, but I am no Rust expert.

Correct, but then again, anything other than machine code is syntatical sugar. So is throw new Exception("oh noes");

>

It means you now loose context

I don't see how.

>

and how do you log?

The same way in pretty much any and all programs written that handles exceptions - some outer loop, possibly in the main function.

> >

To me that was always the issue with error handling without exceptions - how to easily just propagate it up (nearly always what one wants to do). I think they nailed it.

For simple situations maybe, but it looks like a hack, as far as I can tell from the docs.

I disagree. To me, it has all the convenience of exceptions with none of the drawbacks.

November 09

On Tuesday, 9 November 2021 at 11:37:49 UTC, Atila Neves wrote:

>

Correct, but then again, anything other than machine code is syntatical sugar. So is throw new Exception("oh noes");

No, syntactical sugar has nothing to do with the machine. It is sugar if it can be fully/easily replaced by other language constructs with no semantic/typing changes.

You technically can totally restructure a program with exceptions to one without, it is a rather comprehensive transformation.

You usually treat exceptions as a separate construct when reasoning about the type system.

> >

It means you now loose context

I don't see how.

In D you can throw a wide variety of exceptions and propagate them without even knowing that they were thrown. D even retains the exception chain… (perhaps too much context for most use cases). Clearly you loose context by "?" in comparison? Python also allows you to trace the stack… that is a lot of context…

November 09

On Tuesday, 9 November 2021 at 13:26:20 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 9 November 2021 at 11:37:49 UTC, Atila Neves wrote:

> >

It means you now loose context

I don't see how.

In D you can throw a wide variety of exceptions and propagate them without even knowing that they were thrown. D even retains the exception chain… (perhaps too much context for most use cases). Clearly you loose context by "?" in comparison? Python also allows you to trace the stack… that is a lot of context…

If there are no exceptions and one is returning regular values, then the call stack is... the call stack. Given that "?" returns the original failure with whatever extra data it had, I really don't see what the difference is.

16 17 18 19 20 21 22 23 24 25 26 27 28