www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - nothrow by default

reply Steven Schveighoffer <schveiguy gmail.com> writes:
Just wanted to bring this up, and not muddy the other thread.

What do you put if you throw?  safe by default has alternatives. nothrow 
does not. Are we going to get a new keyword/uda?

-Steve
Jan 04 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 4 January 2020 at 16:05:10 UTC, Steven Schveighoffer 
wrote:

 Just wanted to bring this up, and not muddy the other thread.

 What do you put if you throw?  safe by default has 
 alternatives. nothrow does not. Are we going to get a new 
 keyword/uda?

 -Steve


Seems like we'd have to. Or on/off attribute parameters.
Jan 04 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2020 8:06 AM, Mike Parker wrote:

 On Saturday, 4 January 2020 at 16:05:10 UTC, Steven Schveighoffer wrote:

 Just wanted to bring this up, and not muddy the other thread.

 What do you put if you throw?  safe by default has alternatives. nothrow does 
 not. Are we going to get a new keyword/uda?

 -Steve


 
 Seems like we'd have to. Or on/off attribute parameters.


The first step is to add `throw` as a function attribute,

https://github.com/dlang/DIPs/pull/167

The next step will be to make nothrow the default. I have not prepared a DIP
for 
that yet, but will.

The short rationale is that exceptions being a "pay only if you use them" is a 
complete fraud. They're expensive to support, meaning performance programs use 
other ways of signalling errors and use nothrow.
Jan 04 2020
next sibling parent reply JN <666total wp.pl> writes:
On Saturday, 4 January 2020 at 21:38:53 UTC, Walter Bright wrote:

 The first step is to add `throw` as a function attribute,

 https://github.com/dlang/DIPs/pull/167

 The next step will be to make nothrow the default. I have not 
 prepared a DIP for that yet, but will.

 The short rationale is that exceptions being a "pay only if you 
 use them" is a complete fraud. They're expensive to support, 
 meaning performance programs use other ways of signalling 
 errors and use nothrow.


While reusing throw might be convenient, it also makes the code 
less greppable. Kind of like static in C has three different uses.
Jan 04 2020
next sibling parent IGotD- <nise nise.com> writes:
On Saturday, 4 January 2020 at 22:01:48 UTC, JN wrote:

 On Saturday, 4 January 2020 at 21:38:53 UTC, Walter Bright 
 wrote:

 The first step is to add `throw` as a function attribute,

 https://github.com/dlang/DIPs/pull/167

 The next step will be to make nothrow the default. I have not 
 prepared a DIP for that yet, but will.

 The short rationale is that exceptions being a "pay only if 
 you use them" is a complete fraud. They're expensive to 
 support, meaning performance programs use other ways of 
 signalling errors and use nothrow.


 While reusing throw might be convenient, it also makes the code 
 less greppable. Kind of like static in C has three different 
 uses.


I agree, we could use "throws" instead of "throw".
Jan 04 2020
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-01-04 23:01, JN wrote:


 Kind of like static in C has three different uses.


Of like in D, where it has even more uses ;)

-- 
/Jacob Carlborg
Jan 05 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2020 10:57 AM, Jacob Carlborg wrote:

 On 2020-01-04 23:01, JN wrote:
 

 Kind of like static in C has three different uses.


 
 Of like in D, where it has even more uses ;)


It's a long running joke that whenever bikeshedding emerges around choice of a 
keyword, someone proposes "static". And if nobody does step up and propose it,
I 
charge into the breach.
Jan 09 2020
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 4 January 2020 at 21:38:53 UTC, Walter Bright wrote:

 The short rationale is that exceptions being a "pay only if you 
 use them" is a complete fraud. They're expensive to support, 
 meaning performance programs use other ways of signalling 
 errors and use nothrow.


There's more to code than performance. D is an all-purpose 
language.

But anyway, D still allows throwing from nothrow, but only if it 
is the Error class. I presume that would not change.

Would you make throw Error instead just maybe try to print the 
message to stderr then abort? That's not a bad idea, and is 
compatible with D's spec as it stands now. (the print to stderr 
could be problematic in some contexts but we'd just do a runtime 
function override in that case)

Then you wouldn't need any EH framing around it. This could be 
done without changing the default too.


But my worry on nothrow by default in general is then more D code 
will just become fragile since other error methods have 
historically meant they simply get ignored and not even 
reported.... barring something like those newfangled type based 
systems that's probably what we'd become too.

BTW I have some other potential uses for those newfangled type 
based systems. I wouldn't object to getting some of those pieces 
in too - we can already do much of it.

If 1) there was a way to say "ignoring the return value of this 
function is an error" (but that cannot apply everywhere!) and 2) 
be able to return from the caller from a callee (think of C 
macros that like `if(!SUCCEEDED(hr)) return hr` type of thing), I 
think we could do some real magic and have a serious alternative 
to exceptions. And do other useful things too.

My suggestion would be to do those before attempting nothrow by 
default too. (then we can still vote down the default change and 
be left with new tools for people who want to use them :P )
Jan 04 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2020 3:06 PM, Adam D. Ruppe wrote:

 On Saturday, 4 January 2020 at 21:38:53 UTC, Walter Bright wrote:

 The short rationale is that exceptions being a "pay only if you use them" is a 
 complete fraud. They're expensive to support, meaning performance programs use 
 other ways of signalling errors and use nothrow.


 
 There's more to code than performance. D is an all-purpose language.
 
 But anyway, D still allows throwing from nothrow, but only if it is the Error 
 class. I presume that would not change.


I've been thinking about getting rid of Error entirely, and instead using a 
scheme that calls a user-supplied function when things go that wrong. (Error is 
non-recoverable.)



 But my worry on nothrow by default in general is then more D code will just 
 become fragile since other error methods have historically meant they simply
get 
 ignored and not even reported.... barring something like those newfangled type 
 based systems that's probably what we'd become too.


It shouldn't become fragile, because the compiler will reject nothrow code on 
the call stack if an exception is thrown.
Jan 05 2020
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 04 Jan 2020 13:38:53 -0800 schrieb Walter Bright:


 
 The short rationale is that exceptions being a "pay only if you use
 them" is a complete fraud. They're expensive to support, meaning
 performance programs use other ways of signalling errors and use
 nothrow.


I totally agree to that (memory overhead, TypeInfo, support code). In 
addition, this overhead means that exceptions are unlikely to be supported 
in embedded systems, which will lead to a language ecosystem split (this 
effectively happened to C++).

But I'm not sure if that's a good rationale for nothrow by default. We 
already tell users to use exceptions only for "exceptional cases" and use 
other error handling mechanism for common error paths. With this change, 
we'd force users even stronger to use other error handling methods. But 
those don't have language support and we're back to C times, where users 
forget to check error codes, ...


Herb Sutter came to the same conclusion recently and proposed an 
alternative exception implementation for C++. If you didn't see this 
already Walter, it well worth to have a look:

https://www.youtube.com/watch?v=os7cqJ5qlzo
https://www.youtube.com/watch?v=ARYP83yNAWk


I'll summarize the idea here, as far as I remember and adapted to D 
terminology / context:

Rationale: There are two common ways to handle errors: Backtrace/
exception based and error code based. Both have drawbacks (exceptions: 
performance, memory / implementation overhead, not supported in embedded 
systems) (error codes: not "bubbling up" the call stack automatically, no 
way to force user to check, so might accidentially ignore errors).

Solution:
1) Implement exceptions like return codes: Each function which can throw
   returns a union ValueOrError{T result; Error err}. The discriminator
   bit is stored as a CPU flag register which is not  used across
   function calls (e.g. the OVERFLOW status bit). Error is a two-word 
   error code: Error {size_t code; size_t context}. This explains the
   ABI, for now nothing of this is user-visible.

   Whenever a call to a function which might throw occurs and there's a 
   try-catch handler, insert this code after the call:
   if (OVERFLOW == 1)
       goto catch_handler;
   If there's no catch handler installed and a function might throw:
   if (OVERFLOW == 1)
       return;
   The return value is already in the return registers. Therefore
   propagating error codes upwards is cheap.

   The benefits now are simple: Implementation code / memory overhead is
   almost zero, no TypeInfo required, trivial to implement on embedded 
   systems, .... At the same time, exceptions bubble up properly so they
   can't be accidentially unhandled. The runtime overhead in the success 
   case is obviously higher than for some exception systems, but it's
   only a simple conditional jump. It is cheaper than manual error codes,
   as we reuse the same registers for return value and error code, 
   benefitting register allocation. Error propagation also uses the same 
   registers in all functions and is therefore very efficient.


   For D / legacy exception support, you just store  
   code=LEGACY_EXCEPTION, context=Exception pointer. To allocate the 
   error codes in a distributed way and to check 
   for different error types, we can simply store dummy values in the 
   data segment to get unique addresses:
   ubyte OutOfMemoryError; ... ; if (ret.code == &OutOfMemoryError)...

2) (Optional): Herb arguest that because of throw ... it is easy to spot 
   where an exception originates, but it's more difficult to find where 
   an exception was propagated. As a solution, 
   whenever calling a throws function, the calls should be preceeded by
   throw:
   auto value = throw myThrowingFunction();
   Here throw does essentially this: If myThrowingFunction threw, rethrow
   the exception. Otherwise return the return value.

3) (C++ specific): Error codes instead of exceptions, "Type based Errors":
   I don't really know what is meant by this "Type-Based Errors" 
   terminology, seems to be a C++ marketing thing ("we do everything with 
   types now")... The important takeaway is to not allocate complex 
    exception objects. Use the error code and context value. If really 
   more context than one word is necessary, it's still possible to stuff 
   a pointer into context.

4) (D-specific): Not mentioned in the C++ proposal, but some interesting 
   extension: A more local error handling solution:
   In D we have try/catch if we want to handle errors from multiple  
   functions calls and scope(failure) to handle all errors in a function. 
   But fine-grain error handling is annoying:
   -----------------
   try
       foo();
   catch(Exception e)
   {
       switch(e)
       {
           case DNS_ERROR:
               writeln("Dns erorr");
               retry();
           case ...
       }
   }
   // success code here
   -----------------

   quite some overhead here. Traditional error codes are better here:
   -----------------
   T ret;
   switch(ret = foo())
   {
       case ...:
           return;
   }
   // Success here
   -----------------

   Maybe we could formalize this: We can expose the ValueOrError union to 
   the user. foo() then returns ValueOrError!T and the 'throw' in 2) 
   could simply check for errors, otherwise return ValueOrError!(T).value.
   We could then add an opCast(bool) overload to ValueOrError to make
   if (value) work, add a function to check/abort and convert 
   ValueOrError.getValue and overload the switch statement on this:
   -----------------
   auto res = foo();
   switch(res.error)
   {
        case DNS_ERROR:
            return;
        default: // Other error
            return;
   }
   // With flow-typing we'd know that ValueOrError is no error here.   
   Without, we have to explicitly convert the type somehow:

   T value;
   // Switch magically overloaded on error / value tuple
   switch ((value, error) = foo())
   {
       writeln(error);
       return;
   }
   writeln(value);
   -----------------

   However, with these ideas in 4), we'd have to force the user somehow 
   to check the error bit and make the value only accessible after the 
   check.


Caveats:
* I have not thought about how exception chaining fits into all this.
* These exceptions do not naturally propagate through foreign language
  interfaces, although I think we don't guarantee this in D right now
  either.


If there's any real interest in this, I'd be happy to write a proper 
DIP(s) for it (I think 1, 2 and 4 are all independent DIPs). If C++ 
really gets this, we might have to support it anyway for C++ interop.


PS: Back to the original question: nothrow by default: With 2) every 
function which might throw and where errors are not handled locally needs 
to have throw in front of the function call. Obviously, we don't want to 
have too many of these, so nothrow functions should be the common case. 
And the common case should be the default, so nothrow by default also 
makes sense in this context.

-- 
Johannes
Jan 05 2020
next sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Sunday, 5 January 2020 at 10:32:23 UTC, Johannes Pfau wrote:

    The benefits now are simple: Implementation code / memory 
 overhead is
    almost zero, no TypeInfo required, trivial to implement on 
 embedded
    systems, .... At the same time, exceptions bubble up 
 properly so they
    can't be accidentially unhandled. The runtime overhead in 
 the success
    case is obviously higher than for some exception systems, 
 but it's
    only a simple conditional jump. It is cheaper than manual 
 error codes,
    as we reuse the same registers for return value and error 
 code,
    benefitting register allocation. Error propagation also uses 
 the same
    registers in all functions and is therefore very efficient.


Consulting Agner Fox's microarchitecture manual, current Intel 
CPUs still take a performance hit when encountering code with a 
high density of conditional branches. They are sensitive to the 
number of branch instructions per cache line. I've seen GCC pad 
code with NOPs for that reason. AMD's branch predictor, on the 
other hand, is described as perceptron that fares better with 
repeated patterns of branches and isn't tied to the cache. Branch 
mispredictions still hurt a lot (~20 cycles). All 
microcontrollers I'm familiar stall their pipeline on every 
branch if they're pipelined at all.

Moving error handling overhead back into the common/fast code 
path is a step backwards in those cases where performance 
matters. Desktops and servers can absolutely afford to have the 
data overhead associated with exceptions and they benefit the 
most from out of band error handling.

It would be nice to have choice here.


 2) (Optional): Herb arguest that because of throw ... it is 
 easy to spot
    where an exception originates, but it's more difficult to 
 find where
    an exception was propagated. As a solution,
    whenever calling a throws function, the calls should be 
 preceeded by
    throw:
    auto value = throw myThrowingFunction();
    Here throw does essentially this: If myThrowingFunction 
 threw, rethrow
    the exception. Otherwise return the return value.


I hope that this doesn't require code to have a throw keyword in 
every other line. Imagine outer functions of some algorithm where 
the inner functions have a lot of opportunity to fail:

auto result1 = throw step1();
auto result2 = throw step2(result1);
// etc...

The value of the keyword decreases rapidly with the number of 
occurrences.


 3) (C++ specific): Error codes instead of exceptions, "Type 
 based Errors":
    I don't really know what is meant by this "Type-Based Errors"
    terminology, seems to be a C++ marketing thing ("we do 
 everything with
    types now")... The important takeaway is to not allocate 
 complex
     exception objects. Use the error code and context value. If 
 really
    more context than one word is necessary, it's still possible 
 to stuff
    a pointer into context.


There's recently been a talk about error types in C++ and their 
evolution:

https://www.youtube.com/watch?v=coBz_CQ1tJ8&

As with everything in C++, there's a lot of complexity.


 Caveats:
 * I have not thought about how exception chaining fits into all 
 this.


This would require an exception to be allocated that starts the 
chain. The error return value could then turn into a pointer to 
that value. That's similar to how the C++ proposals return 
exceptions in error value returning functions.


 * These exceptions do not naturally propagate through foreign 
 language
   interfaces, although I think we don't guarantee this in D 
 right now
   either.


D exceptions and C++ exception implementations are currently 
quite incompatible, but the documentation still states that that 
is an eventual goal of D:

https://dlang.org/spec/cpp_interface.html#exception-handling
Jan 05 2020
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 05 Jan 2020 12:27:11 +0000 schrieb Gregor Mückl:


 Consulting Agner Fox's microarchitecture manual, current Intel CPUs
 still take a performance hit when encountering code with a high density
 of conditional branches. They are sensitive to the number of branch
 instructions per cache line. I've seen GCC pad code with NOPs for that
 reason. AMD's branch predictor, on the other hand, is described as
 perceptron that fares better with repeated patterns of branches and
 isn't tied to the cache. Branch mispredictions still hurt a lot (~20
 cycles). All microcontrollers I'm familiar stall their pipeline on every
 branch if they're pipelined at all.
 
 Moving error handling overhead back into the common/fast code path is a
 step backwards in those cases where performance matters. Desktops and
 servers can absolutely afford to have the data overhead associated with
 exceptions and they benefit the most from out of band error handling.
 
 It would be nice to have choice here.



This certainly needs to be considered, however: Some languages such as go 
(server!) and C++ with std:error decided to go for error codes for error 
handling. Here the proposal is more efficient and much more safe than 
completely manual error code handling.

Also exceptions can be up to 1000 times slower for the error path. So you 
can now start doing statistics how exceptional your error path has to be 
for exception handling to be more effective. And if the error path is 
taken very rarely, it is easy for the branch predictor to predict. I have 
to admit, if you get rid of allocation and all the other exception 
complexity, the overhead of pure backtracing is probably less. But it's 
still significantly more than a simple branch.

Regarding microcontrollers, how many microcontroller projects use full 
backtracing implementations? Every codebase I've ever seen for these 
systems uses error codes anyway. So Sutter's proposal would not affect 
the performance of these systems at all.

The point about increased branch instruction density hurting the success 
path might still apply. But it's highly dependent on the relative amount 
of functions which actually use error handling. So it seems difficult to 
assess the impact without benchmarking an implementation.



 I hope that this doesn't require code to have a throw keyword in every
 other line. Imagine outer functions of some algorithm where the inner
 functions have a lot of opportunity to fail:
 
 auto result1 = throw step1();
 auto result2 = throw step2(result1);
 // etc...
 
 The value of the keyword decreases rapidly with the number of
 occurrences.


That's certainly true. I think we need some kind of statistics on the 
distribution of nothrow / throw functions in D code here. This would also 
be useful information to make a more informed decision about the throw/
nothrow defaults. As long as calling throwing functions is uncommon, 
making the call explicit should be beneficial.



 There's recently been a talk about error types in C++ and their
 evolution:
 
 https://www.youtube.com/watch?v=coBz_CQ1tJ8&
 
 As with everything in C++, there's a lot of complexity.


Thanks for the link, I'll have a look at this.


 

 Caveats:
 * I have not thought about how exception chaining fits into all this.


 
 This would require an exception to be allocated that starts the chain.
 The error return value could then turn into a pointer to that value.
 That's similar to how the C++ proposals return exceptions in error value
 returning functions.


This is actually similar to the way exception chaining is implemented in 
GDC right now. So that's probably not a hard problem.


 

 * These exceptions do not naturally propagate through foreign language
   interfaces, although I think we don't guarantee this in D
 right now
   either.


 
 D exceptions and C++ exception implementations are currently quite
 incompatible, but the documentation still states that that is an
 eventual goal of D:
 
 https://dlang.org/spec/cpp_interface.html#exception-handling



I was actually more thinking of a call chain like this: dfun1 => cppfun 
=> dfun2. If dfun2 throws an exception, you can actually catch the 
exception in dfun1 (even though you do not know if cppfun properly ran 
its destructors). However, if dfun2 returns an error code union + flag, 
this error information does not propagate to dfun1.

-- 
Johannes
Jan 05 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 15:02:59 UTC, Johannes Pfau wrote:

 This certainly needs to be considered, however: Some languages 
 such as go (server!) and C++ with std:error decided to go for 
 error codes for error handling.


What is "std::error"? If you mean "std::error_code" then it is 
for wrapping OS error codes like the ones from Unix. (You can 
throw it if want...)

The error handling regime in Go is not something anyone should 
copy. The language lacks features that makes code maintainable 
over time. Lots of pointless error-handling boilerplate noise. 
Also, they didn't do it because of speed, Go is not that fast. 
They did it for no scientific reason, just their own (bad) taste, 
but they later found that they had to add the awful hack that 
resembles exceptions, but is a lot more ugly and clunky. Although 
you can hack it to do what you want, in a rather type-unsafe way. 
So I do that, but Go is the error handling scarecrow of modern 
languages... You don't want to write big programs in Go.

Go I useful for small web services because it has a decent 
runtime, stable language design, few compiler bugs, decent 
web-service libraries and cloud support. However, the language 
itself is pretty primitive (for no good reason).
Jan 05 2020
next sibling parent reply JN <666total wp.pl> writes:
On Sunday, 5 January 2020 at 19:53:59 UTC, Ola Fosheim Grøstad 
wrote:

 However, the language itself is pretty primitive (for no good 
 reason).


There are reasons. A simpler language is easier to manage, both 
for compiler and for IDEs, potentially allowing faster 
development time and better performance/reliability, even if it 
doesn't have powerful features. From Go's FAQ:

**Why does Go not have feature X?**

Every language contains novel features and omits someone's 
favorite feature. Go was designed with an eye on felicity of 
programming, speed of compilation, orthogonality of concepts, and 
the need to support features such as concurrency and garbage 
collection. Your favorite feature may be missing because it 
doesn't fit, because it affects compilation speed or clarity of 
design, or because it would make the fundamental system model too 
difficult.
Jan 05 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 20:22:14 UTC, JN wrote:

 There are reasons. A simpler language is easier to manage, both 
 for compiler and for IDEs, potentially allowing faster 
 development time and better performance/reliability, even if it 
 doesn't have powerful features. From Go's FAQ:


I followed the arguments they put forth when Go first launched. 
People complained loudly about not having good abstraction and 
error handling mechanisms and they (the language designers) were 
rather religious about their position. They are Unix/C/Plan9 
people. Go as a language design does not provide better 
reliability, you are not forced to handle errors properly. (Unix 
APIs are also not great for correctness.) The Go designers found 
that they had to add "exceptions". They found that they had to 
add "generics". Coming in Go2.

When your function gets 100% larger because of the language lacks 
basic abstraction/error handling features then that does not 
improve correctness... Hiding the basic logic flow in error 
handling branching is not good for correctness or maintenance 
either.

They have marketed what it lacks as "good design". Go-people 
parrot it as good design, but that does not make it true...

Fortunately, most server code is simple I/O. So it is OK for 
writing a service, but not great, although the runtime makes up 
for it. Somewhat.
Jan 05 2020
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 20:22:14 UTC, JN wrote:

 **Why does Go not have feature X?**


Oh, now I remember why I completely lost faith in the Go language 
designers.

I asked for asserts, and they absolutely refused and said that 
they would never add asserts because some programmers might use 
it to handle errors... therefore nobody should have them.

So, not having exceptions makes error-handling so tedious that 
some programmers will use asserts to check errors... therefore Go 
also could not have asserts.

Completely backwards and arcane mentality? I think so.
Jan 05 2020
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 05 Jan 2020 19:53:59 +0000 schrieb Ola Fosheim Grøstad:


 On Sunday, 5 January 2020 at 15:02:59 UTC, Johannes Pfau wrote:

 This certainly needs to be considered, however: Some languages such as
 go (server!) and C++ with std:error decided to go for error codes for
 error handling.


 
 What is "std::error"? If you mean "std::error_code" then it is for
 wrapping OS error codes like the ones from Unix. (You can throw it if
 want...)
 


As far as I know, starting from C++11 std::error_code can be extended and 
has been used in newer updates to the C++ standard library instead of 
exceptions. (e.g. there is now a future error category). See https://
akrzemi1.wordpress.com/2017/07/12/your-own-error-code/

std::expected / boost outcome proposals are also related. There certainly 
is a trend away from exception to error-code like systems. But I have to 
admit, I don't know much about C++, so maybe those are bad / non-
representative examples.


 The error handling regime in Go is not something anyone should copy. The
 language lacks features that makes code maintainable over time. Lots of
 pointless error-handling boilerplate noise. Also, they didn't do it
 because of speed, Go is not that fast. They did it for no scientific
 reason, just their own (bad) taste,
 but they later found that they had to add the awful hack that resembles
 exceptions, but is a lot more ugly and clunky. Although you can hack it
 to do what you want, in a rather type-unsafe way.
 So I do that, but Go is the error handling scarecrow of modern
 languages... You don't want to write big programs in Go.
 
 Go I useful for small web services because it has a decent runtime,
 stable language design, few compiler bugs, decent web-service libraries
 and cloud support. However, the language itself is pretty primitive (for
 no good reason).


That's probably true. Still, you can do a exception system with the same 
user facing API but without backtracing. So you get rid of unwind tables 
and the backtrace support code making the failure case faster while 
reducing the performance of the succes case. In that case the only 
question is whether the performance difference is important for some 
applications.

Of course, ideally which backend implementation is used could be an 
implementation detail.

-- 
Johannes
Jan 05 2020
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 05 Jan 2020 21:06:00 +0000 schrieb Johannes Pfau:


 Am Sun, 05 Jan 2020 19:53:59 +0000 schrieb Ola Fosheim Grøstad:
 

 On Sunday, 5 January 2020 at 15:02:59 UTC, Johannes Pfau wrote:

 This certainly needs to be considered, however: Some languages such as
 go (server!) and C++ with std:error decided to go for error codes for
 error handling.


 
 What is "std::error"? If you mean "std::error_code" then it is for
 wrapping OS error codes like the ones from Unix. (You can throw it if
 want...)
 
 


 As far as I know, starting from C++11 std::error_code can be extended
 and has been used in newer updates to the C++ standard library instead
 of exceptions. (e.g. there is now a future error category). See https://
 akrzemi1.wordpress.com/2017/07/12/your-own-error-code/


Though looking at this, it seems they often throw exceptions containing 
these error codes? However, Herb Sutter explicitly mentioned 
std::error_code as causing fragmentation in C++ (e.g. std::filesystem 
uses both exceptions and error_code), see slide at https://youtu.be/
os7cqJ5qlzo?t=764

So I assumed error codes are common in modern C++, but I don't really 
have first-hand experience to say for sure.


-- 
Johannes
Jan 05 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 21:12:39 UTC, Johannes Pfau wrote:

 So I assumed error codes are common in modern C++, but I don't 
 really have first-hand experience to say for sure.


Well, the fun thing about C++ is that nobody can tell you exactly 
what modern C++ is, but it is easy to point out old-style C++... 
Many patterns are outdated, but there are many different "modern" 
patterns as well...

The C++ community is split down the middle. Those that use C++ as 
designed (with exceptions), and those that use C++ as a C 
replacement (without exceptions).

I guess some modules have  been viewed as low level and thus have 
been designed to be usable by both groups.

You also have additions like std::optional that can be used if 
you turn off exceptions. I'm sure we see more in that direction 
if Rust becomes more popular...
Jan 05 2020
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 21:06:00 UTC, Johannes Pfau wrote:

 As far as I know, starting from C++11 std::error_code can be 
 extended and has been used in newer updates to the C++ standard 
 library instead of exceptions. (e.g. there is now a future 
 error category). See https:// 
 akrzemi1.wordpress.com/2017/07/12/your-own-error-code/

 std::expected / boost outcome proposals are also related. There 
 certainly is a trend away from exception to error-code like 
 systems. But I have to admit, I don't know much about C++, so 
 maybe those are bad / non- representative examples.


Oh! I see where you are coming from. So, in D you have the 
problem that large sections of the standard library cannot be 
used with out the GC. In C++ you have a similar problem with not 
being able to use most of the standard library (safely) if you 
turn off exceptions. So they have both tried to make the code gen 
for exception code better, but I believe there also is an effort 
to make more of the standard library usable for those who choose 
to turn off exceptions.



 That's probably true. Still, you can do a exception system with 
 the same user facing API but without backtracing. So you get 
 rid of unwind tables and the backtrace support code making the 
 failure case faster while reducing the performance of the 
 succes case. In that case the only question is whether the 
 performance difference is important for some applications.

 Of course, ideally which backend implementation is used could 
 be an implementation detail.


There are absolutely many paths to new (or old) interesting error 
handling/resource management mechanisms. E.g. some research 
language for system programming have used arenas with compiler 
backing and other have explored other alternatives.

But D has to figure out how to relate to C++. Doing the opposite 
of C++ just on the syntax level (throw/nothrow/noexcept), does 
not make much sense if D is to attract C++ developers. It has to 
be substantially better to have an impact, like you suggest.
Jan 05 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2020 4:27 AM, Gregor Mückl wrote:

 It would be nice to have choice here.
 

 2) (Optional): Herb arguest that because of throw ... it is easy to spot
    where an exception originates, but it's more difficult to find where
    an exception was propagated. As a solution,
    whenever calling a throws function, the calls should be preceeded by
    throw:
    auto value = throw myThrowingFunction();
    Here throw does essentially this: If myThrowingFunction threw, rethrow
    the exception. Otherwise return the return value.


 
 I hope that this doesn't require code to have a throw keyword in every other 
 line.


For D, the `throw` attribute will apply to the function, not the statement.
Jan 08 2020
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 10:32:23 UTC, Johannes Pfau wrote:

 I totally agree to that (memory overhead, TypeInfo, support 
 code). In addition, this overhead means that exceptions are 
 unlikely to be supported in embedded systems, which will lead 
 to a language ecosystem split (this effectively happened to 
 C++).


Not only the overhead, but in real-time interrupts have to be 
100% sure that no code triggers a system call or ends up waiting 
for a lock to be released. Also in applications (e.g. audio 
drivers).

Seems to me that static analysis could be used for this, the same 
way  nogc works.  I think D should look at something more 
comprehensive regarding managing resources instead of these  
tweaks that have very little positive impact.



 Rationale: There are two common ways to handle errors: 
 Backtrace/ exception based and error code based. Both have 
 drawbacks (exceptions: performance, memory / implementation 
 overhead, not supported in embedded systems) (error codes: not 
 "bubbling up" the call stack automatically, no way to force 
 user to check, so might accidentially ignore errors).


Yes, but back-tracing with error codes can be slow.

RAII can be slow.

You can have exceptions in real time systems (setjmp), basically 
just reload saved register values that sets the stack pointer and 
program counter to a consistent state.

So an exception (set jump) can be  much faster than back-tracing 
if you have no RAII on the call stack and all allocations are 
done either on the stack and all other resources are bound to an 
Arena-allocator/manager at the landing pad.

What makes C++-style exceptions slow is the unwind library's 
cross-language design and the surrounding RAII philosophy... 
Exceptions, as a concept, are not necessarily slow. If you can 
just set the stack pointer and jump to the landing pad then you 
have something much faster than returning/unwinding down the call 
stack for deep call-trees.

But since D should be able to call C++ code that won't work, and 
nothrow by default will not help with C++. So to get anywhere you 
first have to figure out how to interact with C++ code. If you 
call C++ code then you cannot assume that it won't throw, unless 
it is marked as "noexcept" and even if it is noexcept it still 
can have landing pads. So you cannot bypass the unwinding 
library... Am I right?

In terms of supporting generic programming it is better to have 
"possibly throws" everywhere.
Jan 05 2020
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
There is another exception handling mechanism which has not been 
seriously suggested up until now, but now may be the time for it.

The basics are the same.
Up in the call tree is some sort of handler registered.
This will be a delegate. It returns an enum.

This enum will typically have members like error, prematureReturn, 
continue, and unroll.

The way this delegate get used is that it gets matched bottom up (like 
we do now), in the thrower. The throw statement will match the delegate 
to the exception, call the delegate and then proceed to do whatever that 
function tells it to do. It could assert out, return Return.init, 
continue doing stuff (which may lead to asserting out), or unroll to the 
handling point (which is what we want to avoid).

As this would be D only, it could be a lot cheaper and may not exhibit 
the same limitations as we have now.
Jan 05 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 13:12:47 UTC, rikki cattermole wrote:

 The way this delegate get used is that it gets matched bottom 
 up (like we do now), in the thrower. The throw statement will 
 match the delegate to the exception, call the delegate and then 
 proceed to do whatever that function tells it to do. It could 
 assert out, return Return.init, continue doing stuff (which may 
 lead to asserting out), or unroll to the handling point (which 
 is what we want to avoid).


When exceptions were discussed in the 80s/90s people looked at 
recovery that kinda works they way you describe. So when a 
function fails it can stop and then let some other unit fix the 
problem and then resume where it halted.

I guess you could do this with coroutines in some elegant fashion.

The problem is really writing the code in a recoverable fashion, 
which most programmers seem to not be able to do, hence the 
current "transactional" model of unrolling and the retrying from 
scratch.

With transactional memory and perhaps even a more generic 
transactional concept that also covers external resources then 
you could have complete unrolling without programmer intervention 
(so that no RAII/destructors have to be written). But that is 
rather advanced... and more like research topic I guess.
Jan 05 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 06/01/2020 2:21 AM, Ola Fosheim Grøstad wrote:

 On Sunday, 5 January 2020 at 13:12:47 UTC, rikki cattermole wrote:

 The way this delegate get used is that it gets matched bottom up (like 
 we do now), in the thrower. The throw statement will match the 
 delegate to the exception, call the delegate and then proceed to do 
 whatever that function tells it to do. It could assert out, return 
 Return.init, continue doing stuff (which may lead to asserting out), 
 or unroll to the handling point (which is what we want to avoid).


 
 When exceptions were discussed in the 80s/90s people looked at recovery 
 that kinda works they way you describe. So when a function fails it can 
 stop and then let some other unit fix the problem and then resume where 
 it halted.



Yeah there are quite a few variations on this model and I only know the 
basics.

I don't think we would need the exception handler delegate to "fix" the 
problem per-say, only determine what the user code wants to do. But 
perhaps a company like WekaIO has a use case I haven't thought about 
that would make this a killer feature for them.


 I guess you could do this with coroutines in some elegant fashion.
 
 The problem is really writing the code in a recoverable fashion, which 
 most programmers seem to not be able to do, hence the current 
 "transactional" model of unrolling and the retrying from scratch.


Yes. IMO the two most likely used out comes would be rethrows or to 
return prematurely.


 With transactional memory and perhaps even a more generic transactional 
 concept that also covers external resources then you could have complete 
 unrolling without programmer intervention (so that no RAII/destructors 
 have to be written). But that is rather advanced... and more like 
 research topic I guess.



When I described unrolling, I do mean unrolling using the exception 
handling mechanism.



Just an idea:

try {

} catch(Exception e) {
//	continue throw;
//	continue;
//	break;
}

Any of the statements in the catch block would opt-in to this new 
mechanism, with the default remaining what we have now.

We could also support some sort of typedef'd tuple or random struct's, 
that would force into this new mechanism and default to assert(0);
Jan 05 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 13:32:24 UTC, rikki cattermole wrote:

 When I described unrolling, I do mean unrolling using the 
 exception handling mechanism.


But how will it be faster if it doesn't recover on the spot?

So, if you have an object like the one you propose you could also 
make that object a resource manager (held in thread local 
storage). Then you don' t have to unwind. You just free all the 
resources the object is holding onto, set a new stack pointer and 
load in the landing pad in the program counter.

But you need a smart compiler, strict type checking and a 
cleverly designed runtime.

Anyway, C++ deprecated the the "throw" specifier in C++11 and 
removed it  completely in C++20. Not sure why D users will be 
more accepting of having to specify "throw".

More patient user base perhaps.
Jan 05 2020
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 06/01/2020 2:51 AM, Ola Fosheim Grøstad wrote:

 On Sunday, 5 January 2020 at 13:32:24 UTC, rikki cattermole wrote:

 When I described unrolling, I do mean unrolling using the exception 
 handling mechanism.


 
 But how will it be faster if it doesn't recover on the spot?


If you tell it to unwind, it won't.
The idea is to either assert out or return from the erroring function 
and let the parent figure it out.
Jan 05 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 5 January 2020 at 13:56:14 UTC, rikki cattermole wrote:

 On 06/01/2020 2:51 AM, Ola Fosheim Grøstad wrote:

 But how will it be faster if it doesn't recover on the spot?


 If you tell it to unwind, it won't.
 The idea is to either assert out or return from the erroring 
 function and let the parent figure it out.


But I think that the concern that people have is that the codegen 
will generate landingpads for all stackframes that either catch 
exceptions or call destructors. And that those landingpads make 
writing the code optimization stages more difficult.
Jan 05 2020
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 06/01/2020 3:27 AM, Ola Fosheim Grøstad wrote:

 On Sunday, 5 January 2020 at 13:56:14 UTC, rikki cattermole wrote:

 On 06/01/2020 2:51 AM, Ola Fosheim Grøstad wrote:

 But how will it be faster if it doesn't recover on the spot?


 If you tell it to unwind, it won't.
 The idea is to either assert out or return from the erroring function 
 and let the parent figure it out.


 
 But I think that the concern that people have is that the codegen will 
 generate landingpads for all stackframes that either catch exceptions or 
 call destructors. And that those landingpads make writing the code 
 optimization stages more difficult.


If you use nothrow, the unwinding option would be disabled, so none of 
that would be a problem.

But you would lose the ability unwind, I don't think we can do anything 
about that right now.
Jan 05 2020
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 5 January 2020 at 13:51:33 UTC, Ola Fosheim Grøstad 
wrote:

 Anyway, C++ deprecated the the "throw" specifier in C++11 and 
 removed it  completely in C++20. Not sure why D users will be 
 more accepting of having to specify "throw".

 More patient user base perhaps.


C++ remove exception specification but kept `noexcept` and 
`throw()` both of which behave like the desired `throw` discussed 
here for D.
Jan 10 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 10 January 2020 at 15:43:35 UTC, Jesse Phillips wrote:

 C++ remove exception specification but kept `noexcept` and 
 `throw()` both of which behave like the desired `throw` 
 discussed here for D.


No, "throw()" is not only deprecated, it is removed in C++20.
Jan 10 2020
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 10 January 2020 at 16:01:26 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 10 January 2020 at 15:43:35 UTC, Jesse Phillips 
 wrote:

 C++ remove exception specification but kept `noexcept` and 
 `throw()` both of which behave like the desired `throw` 
 discussed here for D.


 No, "throw()" is not only deprecated, it is removed in C++20.


My searches come up empty handed, but I'm applying the incorrect 
semantics to throw(), that is equal to the noexcept semantics 
which is equal to D's nothrow. I don't see the same proposed 
semantics in c++.
Jan 10 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 10 January 2020 at 16:32:33 UTC, Jesse Phillips wrote:

 My searches come up empty handed, but I'm applying the 
 incorrect semantics to throw(), that is equal to the noexcept 
 semantics which is equal to D's nothrow. I don't see the same 
 proposed semantics in c++.


That's right. C++ has the "noexcept" speficier which also can be 
expressed as "noexcept(true)" in generic programming, but the 
default is "noexcept(false)" (with a few special cases).

The C++ semantics is the opposite of nothrow by default.
Jan 10 2020
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 10 January 2020 at 16:46:32 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 10 January 2020 at 16:32:33 UTC, Jesse Phillips 
 wrote:

 My searches come up empty handed, but I'm applying the 
 incorrect semantics to throw(), that is equal to the noexcept 
 semantics which is equal to D's nothrow. I don't see the same 
 proposed semantics in c++.


 That's right. C++ has the "noexcept" speficier which also can 
 be expressed as "noexcept(true)" in generic programming, but 
 the default is "noexcept(false)" (with a few special cases).

 The C++ semantics is the opposite of nothrow by default.


My point is c++ is not removing what is being proposed for adding 
'throw'
Jan 10 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 10 January 2020 at 22:00:08 UTC, Jesse Phillips wrote:

 My point is c++ is not removing what is being proposed for 
 adding 'throw'


What do you mean? C++ has "throw" as the default. Noexcept is the 
outlier, so yes, they did remove it.
Jan 10 2020
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 10 January 2020 at 22:27:35 UTC, Ola Fosheim Grostad 
wrote:

 On Friday, 10 January 2020 at 22:00:08 UTC, Jesse Phillips 
 wrote:

 My point is c++ is not removing what is being proposed for 
 adding 'throw'


 What do you mean? C++ has "throw" as the default. Noexcept is 
 the outlier, so yes, they did remove it.


Throw was always the default, just like D.
Jan 11 2020
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, January 11, 2020 1:02:09 AM MST Jesse Phillips via Digitalmars-
d wrote:

 On Friday, 10 January 2020 at 22:27:35 UTC, Ola Fosheim Grostad

 wrote:

 On Friday, 10 January 2020 at 22:00:08 UTC, Jesse Phillips

 wrote:

 My point is c++ is not removing what is being proposed for
 adding 'throw'


 What do you mean? C++ has "throw" as the default. Noexcept is
 the outlier, so yes, they did remove it.


 Throw was always the default, just like D.


Yes. What C++ had was a runtime attempt at what Java does. You would
optionally specify which exceptions could be thrown from a function (whereas
in Java, it's mandatory to specify). So, if you had

int foo(std::string bar);

then the function could throw anything (even stuff like int, since C++
didn't restrict exception types at all), whereas if you had

int foo(std::string bar) throw(MyExceptionType);

then the function could only throw the type MyExceptionType. This is similar
to Java, but whereas Java statically restricts what can be thrown, C++ did
it at runtime. So, there were _zero_ compile-time checks that no other types
were thrown, and if something else were thrown, it would basically kill your
program. This was a terrible, terrible idea, which is why they started
phasing it out with C++11.

The one aspect of it which was arguably a good idea was throw() - e.g.

int foo(std::string bar) throw();

which was their version of nothrow. It was still a runtime check, but there
are cases where you absolutely can't have an exception be thrown
(destructors being the primary use case), so while it's still bad that it's
a runtime check, it's deemed better to kill the program in such a case than
to continue. So, C++11 introduced noexcept to replace it. e.g.

int foo(std::string bar) noexcept;

noexcept does the same thing as throw(), but throw() is going away along
with throw(MyExceptionType). So, with throw(...) removed, C++ ends up with a
solution similar to what we currently have in D except that noexcept is a
runtime check, whereas nothrow is a compile-time check, and D lets
non-Exception Throwables be thrown anyway, which can get a bit weird.

If we were to add throw as a function attribute and make nothrow the
default, that would be the opposite of what C++ has, just like it's the
opposite of what we currently have in D.

- Jonathan M Davis
Jan 11 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 11 January 2020 at 14:38:50 UTC, Jonathan M Davis 
wrote:

 noexcept does the same thing as throw(), but throw() is going 
 away along


Not quite. In c++17 throw() was redefined to noexcept, but prior 
to this it should unwind the stack with unexpected as the 
exception. Noexcept may or may not unwind the stack and allow 
optimizations.


 with throw(MyExceptionType). So, with throw(...) removed, C++ 
 ends up with a
 solution similar to what we currently have in D except that 
 noexcept is a


Noexcept is now part of the function type and you can test 
expressions with the noexcept operator. I believe it is more to 
support generic programming and optimization than to prevent bad 
behaviour.
Jan 11 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 11 January 2020 at 22:57:22 UTC, Ola Fosheim Grostad 
wrote:

 On Saturday, 11 January 2020 at 14:38:50 UTC, Jonathan M Davis 
 wrote:

 noexcept does the same thing as throw(), but throw() is going 
 away along


 Not quite. In c++17 throw() was redefined to noexcept, but 
 prior to this it should unwind the stack with unexpected as the 
 exception.


The unexpected handler ( not a regular exception).
Jan 11 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
I'm aware that C++ is moving away from exceptions. I've been unhappy with 
exceptions for some time now (DMD doesn't use them for performance reasons),
and 
C++ has evidently come to the same conclusion.

I expect that exceptions will soon become a legacy feature.
Jan 08 2020
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, January 8, 2020 11:26:41 PM MST Walter Bright via Digitalmars-
d wrote:

 I'm aware that C++ is moving away from exceptions. I've been unhappy with
 exceptions for some time now (DMD doesn't use them for performance
 reasons), and C++ has evidently come to the same conclusion.

 I expect that exceptions will soon become a legacy feature.


I would really hope not. IMHO, they are usually by far the best way to
handle error conditions in a program. Anything else results in you having to
deal with the various possible error conditions when the function returns,
which is _far_ more unwieldy and much more error-prone. It also doesn't work
well with function call chaining.

By using exceptions, you eliminate the need to have error-handling code
everywhere in your program, and unlike stuff like error codes, exceptions
don't get eaten unless the programmer specifically puts in effort to make it
happen.

I wouldn't mind us getting rid of Error in favor of killing the program on
the spot, since that's actually better for debugging, and it avoids the
whole argument about whether it's okay to catch Errors. However, Exceptions
are for runtime conditions that aren't necessarily a bug, and they can often
be recovered from. So, being able to throw Exceptions is extremely useful,
and the fact that they don't force you to check for error conditions
everyewhere and instead just handle them in the spots where it makes sense
to handle them makes the code _way_ cleaner.

IMHO, having nothrow be the default would be terrible, and trying to treat
exceptions as a legacy feature would be even worse.

- Jonathan M Davis
Jan 09 2020
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis 
wrote:

 On Wednesday, January 8, 2020 11:26:41 PM MST Walter Bright via 
 Digitalmars- d wrote:

 [...]


 I would really hope not. IMHO, they are usually by far the best 
 way to handle error conditions in a program. Anything else 
 results in you having to deal with the various possible error 
 conditions when the function returns, which is _far_ more 
 unwieldy and much more error-prone. It also doesn't work well 
 with function call chaining.

 [...]


I absolutely agree with all your points. From a compiler 
developer view, Walter is right. But from an application 
developer view, reducing the usability of Exceptions is terrible 
bad.

Kind regards
Andre
Jan 09 2020
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis 
wrote:

 I wouldn't mind us getting rid of Error in favor of killing the 
 program on the spot, since that's actually better for 
 debugging, and it avoids the whole argument about whether it's 
 okay to catch Errors.


Yes please!


 However, Exceptions are for runtime conditions that aren't 
 necessarily a bug, and they can often be recovered from. So, 
 being able to throw Exceptions is extremely useful, and the 
 fact that they don't force you to check for error conditions 
 everyewhere and instead just handle them in the spots where it 
 makes sense to handle them makes the code _way_ cleaner.

 IMHO, having nothrow be the default would be terrible, and 
 trying to treat exceptions as a legacy feature would be even 
 worse.

 - Jonathan M Davis


+1, and I would add that when writing modern C++11 with only 
linear types, exceptions + RAII quickly appear as the _only way_ 
to have correct desctruction teardown in error conditions (the 
least tested pathes).
Anything else is just bring undetected errors in error paths, 
like in C. GC only catches non-reclaimed memory...
Jan 09 2020
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis 
wrote:

 On Wednesday, January 8, 2020 11:26:41 PM MST Walter Bright via 
 Digitalmars- d wrote:

 I'm aware that C++ is moving away from exceptions. I've been 
 unhappy with exceptions for some time now (DMD doesn't use 
 them for performance reasons), and C++ has evidently come to 
 the same conclusion.

 I expect that exceptions will soon become a legacy feature.


 I would really hope not. IMHO, they are usually by far the best 
 way to handle error conditions in a program. Anything else 
 results in you having to deal with the various possible error 
 conditions when the function returns, which is _far_ more 
 unwieldy and much more error-prone. It also doesn't work well 
 with function call chaining.


I doubt Stroustrup will let that happen. Highly unlikely scenario.

Not sure why anyone would think that exceptions are gone just 
because some want to enable compilers configured to compile 
without exceptions to use more library containers (like 
std::vector)?

  C++17 certainly introduced new exceptions 
(std::filesystem::filesystem_error), and I believe more C++ 
setups enable exceptions today than a decade ago. For good 
reasons.

No need to avoid exceptions in the whole program just because you 
don't want them in som specific locations (like render code).

Whole program analysis and inter-procedural analysis should be 
able to take care of it.
Jan 09 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 9 January 2020 at 13:26:36 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis 
 wrote:

 On Wednesday, January 8, 2020 11:26:41 PM MST Walter Bright 
 via Digitalmars- d wrote:

 I'm aware that C++ is moving away from exceptions. I've been 
 unhappy with exceptions for some time now (DMD doesn't use 
 them for performance reasons), and C++ has evidently come to 
 the same conclusion.

 I expect that exceptions will soon become a legacy feature.


 I would really hope not. IMHO, they are usually by far the 
 best way to handle error conditions in a program. Anything 
 else results in you having to deal with the various possible 
 error conditions when the function returns, which is _far_ 
 more unwieldy and much more error-prone. It also doesn't work 
 well with function call chaining.


 I doubt Stroustrup will let that happen. Highly unlikely 
 scenario.

 Not sure why anyone would think that exceptions are gone just 
 because some want to enable compilers configured to compile 
 without exceptions to use more library containers (like 
 std::vector)?

  C++17 certainly introduced new exceptions 
 (std::filesystem::filesystem_error), and I believe more C++ 
 setups enable exceptions today than a decade ago. For good 
 reasons.

 No need to avoid exceptions in the whole program just because 
 you don't want them in som specific locations (like render 
 code).

 Whole program analysis and inter-procedural analysis should be 
 able to take care of it.


Unfortunately Stroustrup only has its own vote and lobbying in 
what concerns C++'s future, hence his set of advocacy papers 
regarding C++'s roadmap.

As posted in another comment, C++/WinRT and Android NDK are two 
such C++ setups.
Jan 09 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 9 January 2020 at 13:45:44 UTC, Paulo Pinto wrote:

 As posted in another comment, C++/WinRT and Android NDK are two 
 such C++ setups.


I don't use NDK, but the documentation states clearly that it 
only supports new and delete for historic reasons:

«C++ exceptions are supported by libc++, but they are disabled by 
default in ndk-build. This is because historically C++ exceptions 
were not available in the NDK. CMake and standalone toolchains 
have C++ exceptions enabled by default.»

https://developer.android.com/ndk/guides/cpp-support
Jan 09 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 9 January 2020 at 14:16:38 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 9 January 2020 at 13:45:44 UTC, Paulo Pinto wrote:

 As posted in another comment, C++/WinRT and Android NDK are 
 two such C++ setups.


 I don't use NDK, but the documentation states clearly that it 
 only supports new and delete for historic reasons:

 «C++ exceptions are supported by libc++, but they are disabled 
 by default in ndk-build. This is because historically C++ 
 exceptions were not available in the NDK. CMake and standalone 
 toolchains have C++ exceptions enabled by default.»

 https://developer.android.com/ndk/guides/cpp-support


Ah, the Android documentation, where Medium posts by Google 
employees and twitter posts, and back in the day G+ posts, are 
more up to date than the actual documentation.

https://android.googlesource.com/platform/ndk/+/ndk-r14-release/CHANGELOG.md

"RTTI and exceptions are now on by default. This was done for 
improved compatibility with existing CMake projects. See 
https://github.com/android-ndk/ndk/issues/212."
Jan 09 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 9 January 2020 at 16:19:19 UTC, Paulo Pinto wrote:

 Ah, the Android documentation, where Medium posts by Google 
 employees and twitter posts, and back in the day G+ posts, are 
 more up to date than the actual documentation.


But the change log does not contradict the documentation... It 
says that exceptions/STL are not shipped in the system runtime, 
but has to be embedded in the app bundle.

Anyway, it does not matter. The point was only that it was for 
historic reasons, and that supporting exceptions are part of the 
available platform.
Jan 09 2020
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis 
wrote:


 IMHO, having nothrow be the default would be terrible, and 
 trying to treat exceptions as a legacy feature would be even 
 worse.


+1

Huge mistake in terms of programmer convenience. I don't really 
care what Rust or other languages are doing. I'm using D right 
now for a reason.
Jan 09 2020
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09.01.20 11:32, Jonathan M Davis wrote:

 I wouldn't mind us getting rid of Error in favor of killing the program on
 the spot, since that's actually better for debugging,


It really depends. There are situations where it may be better, but if 
you are trying to debug a non-deterministic condition that happens very 
rarely on someone else's machine exclusively in release builds, 
depending on a lot of user input, druntime shutting down the code that 
is supposed to collect enough information for you to have a chance to 
figure out what is going on in detail can hardly be described as 
"better". It should be possible to hook the kill function at least.
Jan 09 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/9/2020 2:10 PM, Timon Gehr wrote:

 On 09.01.20 11:32, Jonathan M Davis wrote:

 I wouldn't mind us getting rid of Error in favor of killing the program on
 the spot, since that's actually better for debugging,


 
 It really depends. There are situations where it may be better, but if you are 
 trying to debug a non-deterministic condition that happens very rarely on 
 someone else's machine exclusively in release builds, depending on a lot of
user 
 input, druntime shutting down the code that is supposed to collect enough 
 information for you to have a chance to figure out what is going on in detail 
 can hardly be described as "better". It should be possible to hook the kill 
 function at least.


Hooking the kill function is the way to do that - much better than exception 
unwinding.
Jan 09 2020
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10.01.20 02:28, Walter Bright wrote:

 On 1/9/2020 2:10 PM, Timon Gehr wrote:

 On 09.01.20 11:32, Jonathan M Davis wrote:

 I wouldn't mind us getting rid of Error in favor of killing the 
 program on
 the spot, since that's actually better for debugging,


 It really depends. There are situations where it may be better, but if 
 you are trying to debug a non-deterministic condition that happens 
 very rarely on someone else's machine exclusively in release builds, 
 depending on a lot of user input, druntime shutting down the code that 
 is supposed to collect enough information for you to have a chance to 
 figure out what is going on in detail can hardly be described as 
 "better". It should be possible to hook the kill function at least.


 
 Hooking the kill function is the way to do that - much better than 
 exception unwinding.


Exception unwinding gives you a stack trace.
Jan 09 2020
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, January 9, 2020 8:25:17 PM MST Timon Gehr via Digitalmars-d 
wrote:

 On 10.01.20 02:28, Walter Bright wrote:

 On 1/9/2020 2:10 PM, Timon Gehr wrote:

 On 09.01.20 11:32, Jonathan M Davis wrote:

 I wouldn't mind us getting rid of Error in favor of killing the
 program on
 the spot, since that's actually better for debugging,


 It really depends. There are situations where it may be better, but if
 you are trying to debug a non-deterministic condition that happens
 very rarely on someone else's machine exclusively in release builds,
 depending on a lot of user input, druntime shutting down the code that
 is supposed to collect enough information for you to have a chance to
 figure out what is going on in detail can hardly be described as
 "better". It should be possible to hook the kill function at least.


 Hooking the kill function is the way to do that - much better than
 exception unwinding.


 Exception unwinding gives you a stack trace.


A core dump at the point of the error gives you that and more.

- Jonathan M Davis
Jan 09 2020
parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Friday, 10 January 2020 at 06:19:01 UTC, Jonathan M Davis 
wrote:

 A core dump at the point of the error gives you that and more.

 - Jonathan M Davis


If only recovering core dumps was reliable these days! It has 
become fashion to misconfigure systems to forward core dumps to 
systemd-journald where they are promptly discarded because the 
daemon considers the dumps to be too large for hiding them in the 
binary syslog.

Apart from that, a crash handler that somehow logs or displays a 
backtrace is preferable when a crash happened on a user machine. 
Depending on the nature of the application, a core dump might 
contain sensitive information that cannot be legally shared with 
the developer (e.g. an in-memory copy of customer addresses).
Jan 10 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/9/2020 7:25 PM, Timon Gehr wrote:

 Exception unwinding gives you a stack trace.


Stack trace printing can be independent of the exception unwinding system. And 
it doesn't require all the complex tracking of RAII objects and their 
destructors, nor does it require executing code in the upstack functions.
Jan 09 2020
prev sibling parent Mathias Lang <pro.mathias.lang gmail.com> writes:
On Friday, 10 January 2020 at 01:28:35 UTC, Walter Bright wrote:

 On 1/9/2020 2:10 PM, Timon Gehr wrote:

 On 09.01.20 11:32, Jonathan M Davis wrote:

 I wouldn't mind us getting rid of Error in favor of killing 
 the program on
 the spot, since that's actually better for debugging,


 
 It really depends. There are situations where it may be 
 better, but if you are trying to debug a non-deterministic 
 condition that happens very rarely on someone else's machine 
 exclusively in release builds, depending on a lot of user 
 input, druntime shutting down the code that is supposed to 
 collect enough information for you to have a chance to figure 
 out what is going on in detail can hardly be described as 
 "better". It should be possible to hook the kill function at 
 least.


 Hooking the kill function is the way to do that - much better 
 than exception unwinding.


Sounds like a good idea, looking forward to that DIP.

I would consider `nothrow` by default, like others, as seriously 
crippling to the language.
However improving the efficiency, or changing the scheme, sounds 
like it would achieve everyone's goal.

To give an example of a real world issue we have:
- A server handling connections
- We call `formattedWrite` with a `nothrow` sink and `nothrow` 
arguments (`toString` & co)
- `formattedWrite` is not `nothrow`

Why ? Because `std.format` is *full* of `enforce` calls to check 
the format string.
So what should we do with them ? We *could* consider it user 
error (because the programmer didn't provide the proper format 
string) and just bulk-replace it with `Error`.

But now, something as trivial as a wrong format string will crash 
my server, and for an error which is most likely recoverable 
(which is I guess the original reasoning behind the `enforce` 
calls).
And such error are common, and can be in paths that are almost 
never triggered (e.g. an error message when the filesystem is 
full).

So all things considered, having a non-`nothrow` `std.format` 
seems like the best compromise until someone comes up with a 
smart way to solve this without another downside. The same 
reasoning apply to many, many places, and that's why `nothrow` by 
default wouldn't make sense to me.

Note at the moment, you can turn a non-`nothrow` function into a 
`nothrow` function with a single line of code:
```
void myFunc() nothrow
{
     scope (failure) assert(0); // This makes the function 
`nothrow`
     formattedWrite(...);
}
```
So in D, you can have non-`nothrow` function and a backtrace via 
exceptions, or `nothrow` function and a backtrace (abort in 
release mode). I think that we have it pretty good.

P.S: https://issues.dlang.org/show_bug.cgi?id=20487
Jan 10 2020
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:

 I expect that exceptions will soon become a legacy feature.


I've seen no evidence of that whatsoever. Exceptions, like GC, 
are a proven winner in the real world with the vast majority of 
actually existing industry code using them successfully.

Reminder that exceptions were invented because error codes 
*cannot* say the same thing.

There are some new techniques being tried out in some places to 
varying levels of success. Those features are useful for other 
purposes too, so I wouldn't mind D picking some of them up, like 
I said in a previous message.

But even with those available, I expect that error handling mode 
will remain relatively niche because of the enormous success 
exceptions have and have had proven in industry.
Jan 09 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/9/20 7:51 AM, Adam D. Ruppe wrote:

 On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:

 I expect that exceptions will soon become a legacy feature.


 
 I've seen no evidence of that whatsoever. Exceptions, like GC, are a 
 proven winner in the real world with the vast majority of actually 
 existing industry code using them successfully.
 
 Reminder that exceptions were invented because error codes *cannot* say 
 the same thing.
 
 There are some new techniques being tried out in some places to varying 
 levels of success. Those features are useful for other purposes too, so 
 I wouldn't mind D picking some of them up, like I said in a previous 
 message.
 
 But even with those available, I expect that error handling mode will 
 remain relatively niche because of the enormous success exceptions have 
 and have had proven in industry.
 


I could see "nothrow by default" added making it an easier transition to 
Swift-like error handling (errors passed back on the stack, made to look 
like exceptions to user code).

I would like to see dip1008 get some more TLC before we think about 
abandoning exceptions altogether. And switching Errors to non 
throwables, terminate in place with stack trace, would be very useful.

-Steve
Jan 09 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 09, 2020 at 10:07:53AM -0500, Steven Schveighoffer via
Digitalmars-d wrote:

 On 1/9/20 7:51 AM, Adam D. Ruppe wrote:

 On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:

 I expect that exceptions will soon become a legacy feature.


 
 I've seen no evidence of that whatsoever. Exceptions, like GC, are a
 proven winner in the real world with the vast majority of actually
 existing industry code using them successfully.




+1.  This anti-exception sentiment I have a hard time understanding.


[...]

 I could see "nothrow by default" added making it an easier transition
 to Swift-like error handling (errors passed back on the stack, made to
 look like exceptions to user code).


[...]

Now *this* I can stand by.  Which makes me wonder if what's bothering
Walter about exceptions is not so much the concept of exceptions itself,
but their current implementation via stack unwinding, which requires
expensive setup of stack frames and what-not.

But it's possible to implement it differently, while still presenting an
exception-like interface to user code. You could pass errors back on the
stack, or even via a register dedicated for indicating error conditions,
and have the compiler automatically generate code for branching to an
error-handling part of the function (or have user code explicitly test
for it, if they so wish). This can be transparent to user code.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??
Jan 09 2020
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 09 Jan 2020 08:02:16 -0800 schrieb H. S. Teoh:


 On Thu, Jan 09, 2020 at 10:07:53AM -0500, Steven Schveighoffer via
 Digitalmars-d wrote:

 On 1/9/20 7:51 AM, Adam D. Ruppe wrote:

 On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:

 I expect that exceptions will soon become a legacy feature.


 
 I've seen no evidence of that whatsoever. Exceptions, like GC, are a
 proven winner in the real world with the vast majority of actually
 existing industry code using them successfully.




 
 +1.  This anti-exception sentiment I have a hard time understanding.
 
 
 [...]

 I could see "nothrow by default" added making it an easier transition
 to Swift-like error handling (errors passed back on the stack, made to
 look like exceptions to user code).


 [...]
 
 Now *this* I can stand by.  Which makes me wonder if what's bothering
 Walter about exceptions is not so much the concept of exceptions itself,
 but their current implementation via stack unwinding, which requires
 expensive setup of stack frames and what-not.
 
 But it's possible to implement it differently, while still presenting an
 exception-like interface to user code. You could pass errors back on the
 stack, or even via a register dedicated for indicating error conditions,
 and have the compiler automatically generate code for branching to an
 error-handling part of the function (or have user code explicitly test
 for it, if they so wish). This can be transparent to user code.
 
 
 T


I think everyone who wants to move away from exceptions really wants to 
move away from two things:

1) Stack unwinding and the overhead it involves (memory, implementation 
   complexity, ...)
2) (Forced) dynamic allocation of error state. How often do you actually
   use more than 1 word of error state? 

That's basically what Sutter proposes for C++, what I summarized in 
https://forum.dlang.org/post/qusdvn$635$1 digitalmars.com and what you 
quickly summarized in your idea.

AFAICS nobody (few people?) wants to get rid of the high-level try-catch 
exception semantics.

However, some might not want to catch by runtime type but implement the 
catch matching using some kind of error codes. The only thing you loose 
here is having complex exception type trees and catching base classes.

Also as I explained in the linked post, try-catch is fine if you handle 
multiple error sources a once. If you instead have to handle errors for 
each function call individually, a more fine grain solution than

try
{
    auto foo = someFunction();
    try
    {
        foo = someFunction2(foo);
    }
    catch(Exception3 e)
    ...
    catch(Exception4 e)
}
catch(Exception e)
 ...
catch(Exception2 e)

would be useful in addition.

-- 
Johannes
Jan 09 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 09, 2020 at 07:05:24PM -0000, Johannes Pfau via Digitalmars-d wrote:

 Am Thu, 09 Jan 2020 08:02:16 -0800 schrieb H. S. Teoh:


[...]

 I think everyone who wants to move away from exceptions really wants
 to move away from two things:
 
 1) Stack unwinding and the overhead it involves (memory,
    implementation complexity, ...)
 2) (Forced) dynamic allocation of error state. How often do you
    actually use more than 1 word of error state? 


What can you practically throw, though, if you only have 1 word of error
state? I suppose you could store a pointer to some exception object in
there, but then that brings us back to issue (2). Unless you have some
kind of thread-local global for storing exception objects?



 That's basically what Sutter proposes for C++, what I summarized in
 https://forum.dlang.org/post/qusdvn$635$1 digitalmars.com and what you
 quickly summarized in your idea.
 
 AFAICS nobody (few people?) wants to get rid of the high-level
 try-catch exception semantics.


[...]

That's also my suspicion.  It's not really the exceptions themselves
that people object to, but the associated implementation issues.


T

-- 
Just because you can, doesn't mean you should.
Jan 09 2020
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 09 Jan 2020 12:39:57 -0800 schrieb H. S. Teoh:


 On Thu, Jan 09, 2020 at 07:05:24PM -0000, Johannes Pfau via
 Digitalmars-d wrote:

 Am Thu, 09 Jan 2020 08:02:16 -0800 schrieb H. S. Teoh:


 [...]

 I think everyone who wants to move away from exceptions really wants to
 move away from two things:
 
 1) Stack unwinding and the overhead it involves (memory,
    implementation complexity, ...)
 2) (Forced) dynamic allocation of error state. How often do you
    actually use more than 1 word of error state?


 
 What can you practically throw, though, if you only have 1 word of error
 state? I suppose you could store a pointer to some exception object in
 there, but then that brings us back to issue (2). Unless you have some
 kind of thread-local global for storing exception objects?
 


As far as I understood Sutter's proposal it's one word of 'context'. But 
a function actually returns two words (i.e. two words of state), where 
one is the error category and the second is the context. Essentially 
std::error_code. In practice the category code is a pointer to a dummy 
variable in static data. So for example you could do this:

module filesystem;

ubyte FileSystemErrorClass;

enum FileSystemError
{
    doesNotExist,
    PermissionDenied
}

return Error(&FileSystemErrorClass, FileSystemError.doesNotExist);

if (error.class == &FileSystemErrorClass)
{
    auto kind = cast(FileSystemError)error.context;
}

The ErrorClass is really the Tag, the context is then arbitrary (Tag-
specific) data. I.e. you could reference TLS data, but you could just as 
well allocate data manually and store a pointer to heap memory in the 
context.

Obviously users would not write such low level code, that's just the low 
level ABI.

-- 
Johannes
Jan 09 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 9 January 2020 at 21:29:00 UTC, Johannes Pfau wrote:

 As far as I understood Sutter's proposal it's one word of 
 'context'. But a function actually returns two words (i.e. two 
 words of state), where one is the error category and the second


Well, on x86 a register can be 256 bits or more... But AFAIK C++ 
implementations do not allocate memory for exceptions 
dynamically. So you only pay the price of the constructor and 
potential cache miss.
Jan 09 2020
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 09 Jan 2020 21:35:51 +0000 schrieb Ola Fosheim Grøstad:


 On Thursday, 9 January 2020 at 21:29:00 UTC, Johannes Pfau wrote:

 As far as I understood Sutter's proposal it's one word of 'context'.
 But a function actually returns two words (i.e. two words of state),
 where one is the error category and the second


 
 Well, on x86 a register can be 256 bits or more... But AFAIK C++
 implementations do not allocate memory for exceptions dynamically. So
 you only pay the price of the constructor and potential cache miss.



I don't know the details, but I guess that's the throw by value / catch 
by reference idiom in C++. Not sure how it's actually implemented.

In addition to constructor + cache miss you'll also have to do RTTI to 
match the object to the types in the catch handlers (and for the 
downcast).


-- 
Johannes
Jan 09 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 9 January 2020 at 22:39:25 UTC, Johannes Pfau wrote:

 I don't know the details, but I guess that's the throw by value 
 / catch by reference idiom in C++. Not sure how it's actually 
 implemented.


It is implementation defined... in clang it uses a dedicated 
allocator function. But as you can see it does some optimizations:

https://llvm.org/docs/ExceptionHandling.html


 In addition to constructor + cache miss you'll also have to do 
 RTTI to match the object to the types in the catch handlers 
 (and for the downcast).


I assume that is how clang++ does it, but you don't _have_ to use 
RTTI structures. You could do it other ways.  But in C++ 
exceptions tend not to be used on the fast-path (meaning, used 
primarily for unexpected outcomes).
Jan 09 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/9/2020 12:39 PM, H. S. Teoh wrote:

 It's not really the exceptions themselves
 that people object to, but the associated implementation issues.


Yes. They're very costly, even in code that never throws.

An approach I've been using with modest success is to design errors entirely
out 
of the code. For example, in dmd a lot of errors are handled by making a
special 
AST node for "Error". Subsequent code does nothing with Error nodes.

(Analogously to how floating point code deals with errors, it just sets a NaN 
value, which is sticky.)

Another technique is to check for errors in the data first, then the processing 
code does not have to check, and cannot fail.

I enjoy trying to set up an API so it cannot fail, then no special code is 
needed for errors. Of course, this isn't always possible, and isn't a general 
solution. But it's nice when one can make it work.

P.S. I hate throwing constructors, and would force them to be nothrow in D if I 
weren't faced with a tsunami of objection to it :-)
Jan 09 2020
next sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Friday, 10 January 2020 at 01:40:00 UTC, Walter Bright wrote:

 On 1/9/2020 12:39 PM, H. S. Teoh wrote:

 It's not really the exceptions themselves
 that people object to, but the associated implementation 
 issues.


 Yes. They're very costly, even in code that never throws.


The longer this discussion drags on, the more I doubt my 
understanding of this topic.

What exactly is the execution overhead for non-throwing code 
paths?

I believe I understand the overhead once stack unwinding needs to 
be performed, but how is code generation affected for the normal 
path?
Jan 09 2020
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/9/2020 7:42 PM, Gregor Mückl wrote:

 What exactly is the execution overhead for non-throwing code paths?
 
 I believe I understand the overhead once stack unwinding needs to be
performed, 
 but how is code generation affected for the normal path?


You need a mechanism for jumping to the scope guard code. Can't do any code 
motion optimizations across the boundaries of such code. Can't do register 
assignments for variables that are "live" across that boundary.

Just write some code with destructors in C++, compile it with and without 
exceptions enabled, and dump the generated assembler.
Jan 09 2020
parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Friday, 10 January 2020 at 07:06:31 UTC, Walter Bright wrote:

 On 1/9/2020 7:42 PM, Gregor Mückl wrote:

 What exactly is the execution overhead for non-throwing code 
 paths?
 
 I believe I understand the overhead once stack unwinding needs 
 to be performed, but how is code generation affected for the 
 normal path?


 You need a mechanism for jumping to the scope guard code. Can't 
 do any code motion optimizations across the boundaries of such 
 code. Can't do register assignments for variables that are 
 "live" across that boundary.

 Just write some code with destructors in C++, compile it with 
 and without exceptions enabled, and dump the generated 
 assembler.


I played around with this as you suggested. The most concise 
example that I could find where -fno-exceptions makes a 
difference is this:

https://godbolt.org/z/WxnsOm

The version with exceptions reserves a register for something at 
the start of the function (rbp in this case), but I can't tell 
what it's for. It is used in the unwinding handler that is 
appended to the function after the ret instruction.
Jan 10 2020
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 10 January 2020 at 03:42:53 UTC, Gregor Mückl wrote:

 The longer this discussion drags on, the more I doubt my 
 understanding of this topic.

 What exactly is the execution overhead for non-throwing code 
 paths?



My understanding is that there is no overhead for functions that 
transitively don't throw or catch.


It's also my experience that

     A. _the bottlnecksin a program are almost NEVER functions 
that throw_ so why optimize the other parts?

     B. Giving up a little bit of safety for performance ruins all 
potential gains because of the overhead of introducing more bugs. 
Fixing one such bug will negate whatever performance gain.

     C. If you do need performance AND errors (typically: parsing 
without ranges/exceptions vs parsing with error codes) then you 
can resort locally to error codes.

     D. Error codes makes very easy to forget them, misuse them, 
and makes code less readable. They make very easy to conflate 
unrecoverable errors and recoverable errors.


The current internet backlash against exceptions is really 
puzzling to me: it's a sort of _revisionism_ because in the 
trenches exceptions are holding things together so they don't 
break more horribly. It think these people don't know how worse 
it could be.
Jan 10 2020
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 10 January 2020 at 01:40:00 UTC, Walter Bright wrote:

 On 1/9/2020 12:39 PM, H. S. Teoh wrote:

 It's not really the exceptions themselves
 that people object to, but the associated implementation 
 issues.


 Yes. They're very costly, even in code that never throws.

 An approach I've been using with modest success is to design 
 errors entirely out of the code. For example, in dmd a lot of 
 errors are handled by making a special AST node for "Error". 
 Subsequent code does nothing with Error nodes.

 (Analogously to how floating point code deals with errors, it 
 just sets a NaN value, which is sticky.)

 Another technique is to check for errors in the data first, 
 then the processing code does not have to check, and cannot 
 fail.

 I enjoy trying to set up an API so it cannot fail, then no 
 special code is needed for errors. Of course, this isn't always 
 possible, and isn't a general solution. But it's nice when one 
 can make it work.

 P.S. I hate throwing constructors, and would force them to be 
 nothrow in D if I weren't faced with a tsunami of objection to 
 it :-)


Well said. Another option would be functional programming, with 
an explicit either type. But it is not for everyone.

I have found that I don't need exceptions a lot, and when I do, 
it is almost always because I want to take advantage of the fact 
that they add implicit returns up call stack until the nearest 
catch. Then they come in real handy, especially because they are 
transparent to the intermediate functions.

Of course, that is exactly why they are costly.

They works great with IO, but I tend to avoid them for everything 
else.
Jan 10 2020
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:

 I'm aware that C++ is moving away from exceptions. I've been 
 unhappy with exceptions for some time now (DMD doesn't use them 
 for performance reasons), and C++ has evidently come to the 
 same conclusion.

 I expect that exceptions will soon become a legacy feature.


Value type exceptions as proposed by Herb and others are still 
exceptions.

Error codes are just to keep the "exceptions only over by dead 
body" crowd happy, and to try to move them away from 
non-compliant C++ with exceptions and RTTI turned off.

C++/WinRT turns COM error codes into C++ exceptions, Android NDK 
has C++ exceptions enabled by default.
Jan 09 2020
prev sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:

 I expect that exceptions will soon become a legacy feature.


Honestly, to me this sounds like "I don't like/use exceptions 
therefore get rid of them (not as a feature, but just stop using 
it anywhere or make them too annoying to bother with)", which is 
understandable since you mostly seem to work on projects that 
require high-performance (like DMD), but not every project is 
unable to afford the overhead of exceptions.

In terms of making `nothrow` the default, I dread to think of how 
annoying it'd be for a commonly used function in a codebase to 
not be `nothrow`, then having to throw in the `throw` keyword 
into the ever-growing attribute soup for any function that calls 
it. While at the moment if a function is `nothrow`, then it's 
optional for a caller to be `nothrow` so it doesn't stick in my 
face as much.

I guess the same argument could be applied to  safe by default, 
but having to deal with an ` system` function is likely much 
rarer and confined than having to deal with a more widely used 
`throw` function, making it more manageable, while ` safe` also 
provide heavy benefits outside of just "performance".

I fear this will also discourage the use of exceptions, and push 
people to overuse error codes which don't have any standard 
pattern; aren't able to provide additional info beyond the actual 
error itself (e.g. can't provide certain info or values that 
caused the error); require the caller to produce any error 
messages (which might mean functions specifically designed for 
other functions' error codes); and more annoyingly either a type 
that returns both value and error (which isn't too bad, but a bit 
annoying), or requires the caller to pass an out/ref parameter(s) 
in case of an error (again, very annoying to deal with).

I don't know. It just feels like this proposal will add more 
friction with using D in the general case, as a compromise for 
giving extra performance in the niche case.

I'm a bit of a dimwit, so apologies if I've misunderstood how 
this'd end up working, but my current view is that it'd make my 
own experience with D more painful for unequal amount of benefit.
Jan 09 2020
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 4 January 2020 at 21:38:53 UTC, Walter Bright wrote:

 The first step is to add `throw` as a function attribute,

 https://github.com/dlang/DIPs/pull/167

 The next step will be to make nothrow the default. I have not 
 prepared a DIP for that yet, but will.

 The short rationale is that exceptions being a "pay only if you 
 use them" is a complete fraud. They're expensive to support, 
 meaning performance programs use other ways of signalling 
 errors and use nothrow.


Do you have a plan for standardizing an alternative 
recoverable-error-signalling method?  For example `Result` types? 
  Or something else?
Jan 13 2020
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 05/01/2020 5:05 AM, Steven Schveighoffer wrote:

 Just wanted to bring this up, and not muddy the other thread.
 
 What do you put if you throw?  safe by default has alternatives. nothrow 
 does not. Are we going to get a new keyword/uda?
 
 -Steve


Well we could use throw, or add throws like in Java.

But after Java I do think we have the right defaults for exceptions in 
general. The Java way forces you to use the IDE to handle that stuff, 
instead of yourself. Which would be a major loss for D.
Jan 04 2020
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 4 January 2020 at 16:05:10 UTC, Steven Schveighoffer 
wrote:

 We we going to get a new keyword/uda?


this should be done regardless of defaults! for ALL these 
attributes. We should do that and perhaps figure out it going 
into scopes too.

nothrow:
struct A {
    void foo() throws {} // the nothrow could be inherited from 
outside if it is overridable inside.
}


nothrow by default btw I'm.... concerned about. but if we fixed 
the anti-attributes and descending into scopes it is far more 
manageable regardless of default.
Jan 04 2020
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, January 4, 2020 9:05:10 AM MST Steven Schveighoffer via 
Digitalmars-d wrote:

 Just wanted to bring this up, and not muddy the other thread.

 What do you put if you throw?  safe by default has alternatives. nothrow
 does not. Are we going to get a new keyword/uda?


We really should add a way to negate all of the attributes regardless of the
defaults, but nothrow by default would be terrible IMHO. Aside from really
performance-sensitive code, exceptions are usually the best and cleanest way
to deal with error conditions that aren't bugs. If nothrow were the default,
either we'd have to slap whatever the equivalent of !nothrow would be all
over the place, or exceptions would be seriously compromised as a means of
error handling.

- Jonathan M Davis
Jan 04 2020
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Saturday, 4 January 2020 at 16:05:10 UTC, Steven Schveighoffer 
wrote:

 What do you put if you throw?  safe by default has 
 alternatives. nothrow does not. Are we going to get a new 
 keyword/uda?


Walter's current plan seems to be allowing the `throw` keyword to 
be used as an attribute.

https://github.com/dlang/DIPs/pull/167/files

That still leaves the question how  nogc and pure will be 
negated, and how to specify the default attributes for a module 
without affecting template functions and functions with `auto` 
return-type.
Jan 04 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 4 January 2020 at 20:53:34 UTC, Dennis wrote:

 Walter's current plan seems to be allowing the `throw` keyword 
 to be used as an attribute.

 https://github.com/dlang/DIPs/pull/167/files


that looks good to me btw. I'm against the default change but 
that DIP appears to do what I'd want - the negating behavior is 
also well done.


 That still leaves the question how  nogc and pure will be 
 negated, and how to specify the default attributes for a module 
 without affecting template functions and functions with `auto` 
 return-type.


lol we could always use existing keywords like crazy:

pure!false
 nogc!true
nothrow!default
virtual!false

or something similar.

gotta love the double negatives but meh. throw already being a 
keyword is convenient. pure is already positive so convenient. 
just  nogc, the odd one out.

but like regardless i wouldn't oppose such a thing.

i also wouldn't oppose impure and  gc keywords added.


I also wouldn't oppose templates simply not being affected by 
scope-level keyword attributes. That might be a winner 
actually.... maybe. If you want it to apply to the template, 
you'd just have to explicitly write it again. They get special 
case because of the inference rule.

Could also mean

 safe class Foo {
    final void my_template()(); // actually inferred, despite 
outer  safe
}


idk, just throwing out ideas. To be honest I'd take just about 
*anything* that actually happens now over some other idea that we 
have to wait several years for again.
Jan 04 2020
next sibling parent Dennis <dkorpel gmail.com> writes:
On Saturday, 4 January 2020 at 21:07:03 UTC, Adam D. Ruppe wrote:

 lol we could always use existing keywords like crazy:

 pure!false
  nogc!true
 nothrow!default
 virtual!false

 or something similar.

 gotta love the double negatives but meh. throw already being a 
 keyword is convenient. pure is already positive so convenient. 
 just  nogc, the odd one out.


So do you allow `nothrow!false` as well? Or:
- nothrow!(false)
- nothrow!0
- nothrow!(0 || false)
- throw!false
- throw!true

Also, which one gets put in the tuple when calling:

__traits(getFunctionAttributes, func);

Currently " system", " trusted" or " safe" is always there, while 
"nothrow", "pure" and " nogc" are either there or not. What is 
the canonical way to check that a function does not have the 
"nothrow" attribute? When there's multiple options, it's bound to 
be confusing.

It might be bikeshedding over the real issue (which is that it is 
still impossible to negate these attributes at all), but 
considering attribute soup is already a common complaint, I don't 
want it to become worse.
Jan 04 2020
prev sibling next sibling parent Les De Ridder <les lesderid.net> writes:
On Saturday, 4 January 2020 at 21:07:03 UTC, Adam D. Ruppe wrote:

 [...]

 lol we could always use existing keywords like crazy:

 pure!false
  nogc!true
 nothrow!default
 virtual!false

 or something similar.


I had this idea too (for my toy language). One potential problem 
is
 safe/ system/ trusted though, but you could just keep  trusted 
as a
separate attribute.


 [...]

 I also wouldn't oppose templates simply not being affected by 
 scope-level keyword attributes. That might be a winner 
 actually.... maybe. If you want it to apply to the template, 
 you'd just have to explicitly write it again. They get special 
 case because of the inference rule.


This is an interesting idea. How often do you actually want your
templates to be affected by scope-level attributes?
Jan 04 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2020 1:07 PM, Adam D. Ruppe wrote:

 On Saturday, 4 January 2020 at 20:53:34 UTC, Dennis wrote:

 Walter's current plan seems to be allowing the `throw` keyword to be used as 
 an attribute.

 https://github.com/dlang/DIPs/pull/167/files


 
 that looks good to me btw. I'm against the default change but that DIP appears 
 to do what I'd want - the negating behavior is also well done.


Your comment is exactly why I'm doing this as two DIPs instead of one :-)
Jan 04 2020
prev sibling next sibling parent reply apz28 <home home.com> writes:
On Saturday, 4 January 2020 at 21:07:03 UTC, Adam D. Ruppe wrote:

 On Saturday, 4 January 2020 at 20:53:34 UTC, Dennis wrote:

 Walter's current plan seems to be allowing the `throw` keyword 
 to be used as an attribute.

 https://github.com/dlang/DIPs/pull/167/files


 that looks good to me btw. I'm against the default change but 
 that DIP appears to do what I'd want - the negating behavior is 
 also well done.


 That still leaves the question how  nogc and pure will be 
 negated, and how to specify the default attributes for a 
 module without affecting template functions and functions with 
 `auto` return-type.


 lol we could always use existing keywords like crazy:

 pure!false
  nogc!true
 nothrow!default
 virtual!false

 or something similar.

 gotta love the double negatives but meh. throw already being a 
 keyword is convenient. pure is already positive so convenient. 
 just  nogc, the odd one out.

 but like regardless i wouldn't oppose such a thing.

 i also wouldn't oppose impure and  gc keywords added.


 I also wouldn't oppose templates simply not being affected by 
 scope-level keyword attributes. That might be a winner 
 actually.... maybe. If you want it to apply to the template, 
 you'd just have to explicitly write it again. They get special 
 case because of the inference rule.

 Could also mean

  safe class Foo {
    final void my_template()(); // actually inferred, despite 
 outer  safe
 }


 idk, just throwing out ideas. To be honest I'd take just about 
 *anything* that actually happens now over some other idea that 
 we have to wait several years for again.


D should make attribute keywords consistent by adding inversed 
value using "!". This will help to reduce the number of 
attributes and a way to inverse the block setting. For any 
attributes that support block in form of ...":" or ...{...}, it 
should apply to all functions & function/delegate alias.
 trusted is a dangerous construct and should not be allowed to be 
use in block construct.

pure
!pure
 gc
 !gc => as current  nogc and depreciate  nogc
throw
!throw => as current nothrow and depreciate nothrow
 safe
 !safe => as current  system and depreciate  system
Jan 04 2020
parent berni44 <dlang d-ecke.de> writes:
On Sunday, 5 January 2020 at 04:37:57 UTC, apz28 wrote:

 pure
 !pure
  gc
  !gc => as current  nogc and depreciate  nogc
 throw
 !throw => as current nothrow and depreciate nothrow
  safe
  !safe => as current  system and depreciate  system


I would like to have everything with  :  nothrow,  pure,  nopure 
(or ! throw, ! pure but I like  nothrow and  nopure more). And 
one my even think about  const to avoid the ambiguity of "const 
int f()".
Jan 05 2020
prev sibling parent Andrea Fontana <nospam example.com> writes:
On Saturday, 4 January 2020 at 21:07:03 UTC, Adam D. Ruppe wrote:

 pure!false
  nogc!true
 nothrow!default
 virtual!false


nopure / novirtual / no...



#safe #nothrow #nopure
 myuda
void blah()
{
}
Jan 07 2020
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 4 January 2020 at 16:05:10 UTC, Steven Schveighoffer 
wrote:

 Just wanted to bring this up, and not muddy the other thread.

 What do you put if you throw?  safe by default has 
 alternatives. nothrow does not. Are we going to get a new 
 keyword/uda?

 -Steve


WHY would nothrow by the default in the first place?

Exceptions are about the best error handling mechanism and there 
is no better altnernative in D.

There is a rationale for making people use a safe subset 
(supposed to be a good thing) but what is the rationale for 
gently moving them to _avoid exceptions?_

The performance point is a bit strange since people that want 
speed without correctness doesn't neither correctness, nor speed. 
The solution is to make nothrow whatever is slow and will be in 
benchmarks... Textbook premature optimization at the expense of 
correctness.
Jan 05 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 6 January 2020 at 03:13:09 UTC, Guillaume Piolat wrote:

 On Saturday, 4 January 2020 at 16:05:10 UTC, Steven 
 Schveighoffer wrote:

 Just wanted to bring this up, and not muddy the other thread.

 What do you put if you throw?  safe by default has 
 alternatives. nothrow does not. Are we going to get a new 
 keyword/uda?

 -Steve


 WHY would nothrow by the default in the first place?

 Exceptions are about the best error handling mechanism and 
 there is no better altnernative in D.


`nothrow` by default doesn't stop you from using exceptions, it 
just forces you to either catch them or mark your function as 
throwing.
Jan 05 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 January 2020 at 06:58:34 UTC, Paul Backus wrote:

 `nothrow` by default doesn't stop you from using exceptions, it 
 just forces you to either catch them or mark your function as 
 throwing.


It kinda does: generic programming.

Say if I want to do critical math and create a numeric class that 
throws on inaccuracies. Then I cannot use libraries that "forgot" 
to add "throws" because whenever I provide a lambda that use 
critical math those libraries will refuse to take them.

Attributes like "nothrow" should be for public APIs.  For most 
code is better to do this using semantic analysis.
Jan 06 2020
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Monday, 6 January 2020 at 06:58:34 UTC, Paul Backus wrote:

 On Monday, 6 January 2020 at 03:13:09 UTC, Guillaume Piolat 
 wrote:

 On Saturday, 4 January 2020 at 16:05:10 UTC, Steven 
 Schveighoffer wrote:

 Just wanted to bring this up, and not muddy the other thread.

 What do you put if you throw?  safe by default has 
 alternatives. nothrow does not. Are we going to get a new 
 keyword/uda?

 -Steve


 WHY would nothrow by the default in the first place?

 Exceptions are about the best error handling mechanism and 
 there is no better altnernative in D.


 `nothrow` by default doesn't stop you from using exceptions, it 
 just forces you to either catch them or mark your function as 
 throwing.


What do you think people will do:
A - handle the exception correctly at the right place and mark 
the whole chain of calls as `throws`
B - mark a single function as `nothrow` and catch the Exception 
with a dummy handler

B is dangerously easier to do.

Also the statu quo isn't so bad: an unhandled exception crash, 
which is an unrecoverable error, as good as an 
assertion-in-release. Not handling one is a bug, and it acts like 
so.

How many times will D break all code in the future?
Jan 06 2020