Menu
Search

Forums

Forum Index

April 01, 2022
Gravatar of H. S. TeohPosted by H. S. Teoh
in reply to Alexandru Ermicioi		Reply
H. S. Teoh
Gravatar of H. S. Teoh
Posted in reply to Alexandru Ermicioi


Reply
On Fri, Apr 01, 2022 at 09:41:09AM +0000, Alexandru Ermicioi via Digitalmars-d wrote: [...]
> Just wondering, would it be possible to use lubunwind, only in extern c++ declarations?
> 
> I.e. we'd have own exception handling in D code, and C++ compliant exceptions in extern C++ one?
> 
> This would mean that when d code interacts with c++ it will get translated into respective mechanism, from c++ if it is from c++ code called by D code, and into c++ one if it is from extern c++ d code that is called by c++ code.
[...]

That's what I'd propose.  But Walter seems dead set against exceptions in general, so I dunno whether this will ever actually happen.


T

-- 
Lottery: tax on the stupid. -- Slashdotter
April 01, 2022
Gravatar of user1234Posted by user1234
in reply to mee6		Reply
user1234
Gravatar of user1234
Posted in reply to mee6


Reply

On Thursday, 31 March 2022 at 22:05:30 UTC, mee6 wrote:

>

On Thursday, 31 March 2022 at 21:35:00 UTC, user1234 wrote:

>

On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:

>

Rust's error handling is pretty good, I think they've proved the use of Result!(T, E). I was just always getting informative messages from the get go. I think there's a @nogc exception DIP in the works but I think this way of handling errors is better.

I won't go too much into detail of rust as this website does a good job of going over it.

https://doc.rust-lang.org/book/ch09-00-error-handling.html

Anyways this could be adopted instead of trying to get @nogc exceptions working. Rust uses exceptions but only for panic!() Which terminates the application. All it does is rewind the stack to see all the function calls for debugging pretty much.

I also think it works with chaining functions as that's what Rust does a lot too. They have a ? operator that does basically this boiler plate code.

auto result = expr;
if (result.isErr())
    return result;

D could implement this fairly easily and without much intrusion, but it would add a lot of value to be able to do something like:

auto value = chain()?.funcs()?;

yikes, I'd prefer if D could use ? for safe navigation.

>

While being @nogc and without using exceptions. Other than for panics.

That is Rust's equivalent.

https://en.m.wikipedia.org/wiki/Safe_navigation_operator#Rust

yeah, nice. Everyone needs to see that and think twice.

Is Rust awefull afterall ?

April 02, 2022
Gravatar of mesniPosted by mesni
in reply to mee6		Reply
mesni
Gravatar of mesni
Posted in reply to mee6


Reply

On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:

>

Rust's error handling is pretty good, I think they've proved the use of Result!(T, E). I was just always getting informative messages from the get go. I think there's a @nogc exception DIP in the works but I think this way of handling errors is better.

[...]

With an already existing Nullable it looks like this:

auto value = chain().get.funcs().get;

I don't see much difference

April 02, 2022
Gravatar of mesniPosted by mesni
in reply to mee6		Reply
mesni
Gravatar of mesni
Posted in reply to mee6


Reply

On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:

>

Rust's error handling is pretty good, I think they've proved the use of Result!(T, E). I was just always getting informative messages from the get go. I think there's a @nogc exception DIP in the works but I think this way of handling errors is better.

I won't go too much into detail of rust as this website does a good job of going over it.

https://doc.rust-lang.org/book/ch09-00-error-handling.html

Anyways this could be adopted instead of trying to get @nogc exceptions working. Rust uses exceptions but only for panic!() Which terminates the application. All it does is rewind the stack to see all the function calls for debugging pretty much.

I also think it works with chaining functions as that's what Rust does a lot too. They have a ? operator that does basically this boiler plate code.

auto result = expr;
if (result.isErr())
    return result;

D could implement this fairly easily and without much intrusion, but it would add a lot of value to be able to do something like:

auto value = chain()?.funcs()?;

While being @nogc and without using exceptions. Other than for panics.

Moreover, here is an interesting trick

import std.stdio;
import std.typecons;
import std.exception;

    template ErrorGet(alias Func){
        ref auto getn(T)(ref T n){
            if(n.isNull) Func(0);
            return n.get();
        }
    }

alias PanicGet = ErrorGet!((a){assert(a);});
alias ThrowGet = ErrorGet!(enforce);

    void main(){
        Nullable!int a;
        a = 8;
        with(PanicGet){
           	a.getn.writeln;
        }
        with(ThrowGet){
            a.getn.writeln;
        }
     }
     ```
April 02, 2022
Gravatar of mee6Posted by mee6
in reply to mesni		Reply
mee6
Gravatar of mee6
Posted in reply to mesni


Reply

On Saturday, 2 April 2022 at 02:29:16 UTC, mesni wrote:

>

On Thursday, 31 March 2022 at 21:21:04 UTC, mee6 wrote:

>

Rust's error handling is pretty good, I think they've proved the use of Result!(T, E). I was just always getting informative messages from the get go. I think there's a @nogc exception DIP in the works but I think this way of handling errors is better.

[...]

With an already existing Nullable it looks like this:

auto value = chain().get.funcs().get;

I don't see much difference

You don't get the error of why it is null to begin with, and it doesn't forward errors. It is quite different even if the syntax is similar.

April 02, 2022
Gravatar of ryuukk_Posted by ryuukk_
in reply to mee6		Reply
ryuukk_
Gravatar of ryuukk_
Posted in reply to mee6


Reply

In my opinion Rust error handling is one of the worst

I much preffer Go/Zig/Odin, my favorite would be Odin's one

f, err := os.open(...)
if err != os.ERROR_NONE {
    // handle error
}
defer os.close(f) // will be executed at the end of the scope

Multiple returns is the trick!! simple, easy to read and handle, i can understand if one prefer exception sicne they bubble up, even though i think it encourages a lazy design of APIs, for that, then Zig's one will suits you better, since it's more strict about that part

« First   ‹ Prev
1 2
Next ›   Last »