www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "Exceptions will fade away in modern languages"

reply IGotD- <nise nise.com> writes:
I reacted to the comment of Walter Bright about exceptions in the 
"Destroy All Memory Corruption" presentation. The point he made 
that exceptions don't play well with compile time data flow 
analysis. He also mentioned that he thinks that exception will 
become obsolete in the future. Exceptions are used in many 
languages today and even the newest ones so I can't see a trend 
here.

That raises the question what method is going to replace 
exceptions in that case?
Will D introduce an alternative method of error handler that 
plays better with  live?
Nov 21 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 21 November 2020 at 23:05:19 UTC, IGotD- wrote:

 I reacted to the comment of Walter Bright about exceptions in 
 the "Destroy All Memory Corruption" presentation. The point he 
 made that exceptions don't play well with compile time data 
 flow analysis. He also mentioned that he thinks that exception 
 will become obsolete in the future. Exceptions are used in many 
 languages today and even the newest ones so I can't see a trend 
 here.


Exceptions can be modelled with conditionals in static analysis. 
They should work out ok with dataflow analysis.
Nov 21 2020
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 22 November 2020 at 00:09:36 UTC, Ola Fosheim Grostad 
wrote:

 On Saturday, 21 November 2020 at 23:05:19 UTC, IGotD- wrote:

 I reacted to the comment of Walter Bright about exceptions in 
 the "Destroy All Memory Corruption" presentation. The point he 
 made that exceptions don't play well with compile time data 
 flow analysis. He also mentioned that he thinks that exception 
 will become obsolete in the future. Exceptions are used in 
 many languages today and even the newest ones so I can't see a 
 trend here.


 Exceptions can be modelled with conditionals in static 
 analysis. They should work out ok with dataflow analysis.


Only with inter-procedural dataflow anlysis.
Since  live's DFA if intra-procedural (does not the leave 
function body) it cannot model dataflow that may be continued in 
another functions frame.
then again ... perhaps that's not actually and issue, but I 
haven't thought much about it.
Nov 25 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 11:05:06 UTC, Stefan Koch wrote:

 On Sunday, 22 November 2020 at 00:09:36 UTC, Ola Fosheim 
 Grostad wrote:

 On Saturday, 21 November 2020 at 23:05:19 UTC, IGotD- wrote:

 I reacted to the comment of Walter Bright about exceptions in 
 the "Destroy All Memory Corruption" presentation. The point 
 he made that exceptions don't play well with compile time 
 data flow analysis. He also mentioned that he thinks that 
 exception will become obsolete in the future. Exceptions are 
 used in many languages today and even the newest ones so I 
 can't see a trend here.


 Exceptions can be modelled with conditionals in static 
 analysis. They should work out ok with dataflow analysis.


 Only with inter-procedural dataflow anlysis.
 Since  live's DFA if intra-procedural (does not the leave 
 function body) it cannot model dataflow that may be continued 
 in another functions frame.
 then again ... perhaps that's not actually and issue, but I 
 haven't thought much about it.


I think you can do make worst case assumptions, but D should do 
context senditive analysis. Basically, compile summaries (what 
can it throw) for all functions before doing the live analysis. 
It is common to do overapproximations (assume too much, but 
compute fast).
Nov 25 2020
prev sibling parent reply Marcone <marcone email.com> writes:
On Sunday, 22 November 2020 at 00:09:36 UTC, Ola Fosheim Grostad 
wrote:

 On Saturday, 21 November 2020 at 23:05:19 UTC, IGotD- wrote:

 I reacted to the comment of Walter Bright about exceptions in 
 the "Destroy All Memory Corruption" presentation. The point he 
 made that exceptions don't play well with compile time data 
 flow analysis. He also mentioned that he thinks that exception 
 will become obsolete in the future. Exceptions are used in 
 many languages today and even the newest ones so I can't see a 
 trend here.


 Exceptions can be modelled with conditionals in static 
 analysis. They should work out ok with dataflow analysis.


Many conditions to check before jumping, and then you still run 
the risk of some denial. Often everything looks good and ready to 
work, and even then it can give some unknown error. Could the 
entire thread stop working due to a minor error that could be 
tried again?
Jan 05 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 5 January 2021 at 19:17:26 UTC, Marcone wrote:

 On Sunday, 22 November 2020 at 00:09:36 UTC, Ola Fosheim 
 Grostad wrote:

 Exceptions can be modelled with conditionals in static 
 analysis. They should work out ok with dataflow analysis.


 Many conditions to check before jumping, and then you still run 
 the risk of some denial. Often everything looks good and ready 
 to work, and even then it can give some unknown error. Could 
 the entire thread stop working due to a minor error that could 
 be tried again?


Hm? There is no jumping. You can use an algorithm that rewrite 
the code with conditionals instead for analysis. So a jump 
becomes code that have been excluded with an if-statement for 
instance.
Jan 05 2021
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Saturday, 21 November 2020 at 23:05:19 UTC, IGotD- wrote:

 I reacted to the comment of Walter Bright about exceptions in 
 the "Destroy All Memory Corruption" presentation. The point he 
 made that exceptions don't play well with compile time data 
 flow analysis. He also mentioned that he thinks that exception 
 will become obsolete in the future. Exceptions are used in many 
 languages today and even the newest ones so I can't see a trend 
 here.

 That raises the question what method is going to replace 
 exceptions in that case?
 Will D introduce an alternative method of error handler that 
 plays better with  live?


This is well-trodden ground among D's competitors.

Rust has no exceptions (only `panic`, which aborts the current 
thread), and instead opts to use algebraic data types along with 
some light language support. Swift does something very similar.

Go allows an optional return slot for an Error value that you are 
not forced to check, as is typical for Go's approach of choosing 
the worst possible option, but at least it's a slight improvement 
on C. Get used to writing `if err != nil` every other line.

I think Nim actually does have exceptions.
Nov 25 2020
next sibling parent reply Araq <rumpf_a web.de> writes:
On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:

 I think Nim actually does have exceptions.


Correct and the one of the "deterministic" kind (check after 
function calls that can raise). It doesn't require 
"inter-procedural dataflow anlysis" either but hey, what do I 
know, have fun in your nonscientific bubble.
Nov 25 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 23:23:17 UTC, Araq wrote:

 On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:

 I think Nim actually does have exceptions.


 Correct and the one of the "deterministic" kind (check after 
 function calls that can raise). It doesn't require 
 "inter-procedural dataflow anlysis" either but hey, what do I 
 know, have fun in your nonscientific bubble.


 live needs context sensitive analysis to get better precision as 
it tries to match up malloc with free if my understanding is 
correct. So it needs to know what exceptions can occur at each 
function call.

You could also extend  live and make it more useful with global 
flow typing of allocation source (gc vs malloc). For that you 
need inter procedural analysis.
Nov 25 2020
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 25 November 2020 at 23:23:17 UTC, Araq wrote:

 On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:

 I think Nim actually does have exceptions.


 Correct and the one of the "deterministic" kind (check after 
 function calls that can raise). It doesn't require 
 "inter-procedural dataflow anlysis" either but hey, what do I 
 know, have fun in your nonscientific bubble.


I don't understand the hostility. What did I say that was 
"unscientific"? For that matter, I didn't say anything about 
interprocedural analysis.
Nov 25 2020
next sibling parent CraigDillabaugh <craig.dillabaugh gmail.com> writes:
On Thursday, 26 November 2020 at 00:23:01 UTC, Meta wrote:

 On Wednesday, 25 November 2020 at 23:23:17 UTC, Araq wrote:

 On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:

 I think Nim actually does have exceptions.


 Correct and the one of the "deterministic" kind (check after 
 function calls that can raise). It doesn't require 
 "inter-procedural dataflow anlysis" either but hey, what do I 
 know, have fun in your nonscientific bubble.


 I don't understand the hostility. What did I say that was 
 "unscientific"? For that matter, I didn't say anything about 
 interprocedural analysis.


Maybe he is Go developer :o)
Nov 25 2020
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 00:23:01 UTC, Meta wrote:

 On Wednesday, 25 November 2020 at 23:23:17 UTC, Araq wrote:

 On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:

 I think Nim actually does have exceptions.


 Correct and the one of the "deterministic" kind (check after 
 function calls that can raise). It doesn't require 
 "inter-procedural dataflow anlysis" either but hey, what do I 
 know, have fun in your nonscientific bubble.


 I don't understand the hostility. What did I say that was 
 "unscientific"? For that matter, I didn't say anything about 
 interprocedural analysis.


He is the Nim author. :)

But,  live tries to do things that is better done through the 
type system and RAII.
To make RAII work you need exceptions. Removing them would be a 
disaster. What is wrong with make_unique?

The time complexity to do it without type system constraints will 
most likely make  live underwhelming or slow down compilation 
significantly.

Why encourage using malloc directly in the first place?

To get  safe ARC, D needs a global borrow checker to prevent 
dangling interior pointers. Without it, D will be stuck with a 
heavyhanded GC for all  safe code.
Nov 25 2020
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:


 This is well-trodden ground among D's competitors.

 Rust has no exceptions (only `panic`, which aborts the current 
 thread), and instead opts to use algebraic data types along 
 with some light language support. Swift does something very 
 similar.


No, Swift has dedicated syntax for error handling, just like D. 
The syntax looks very much like the syntax used for exceptions. 
The implementation doesn't use table based exceptions but instead 
builds on the Objective-C/Cocoa error handling style. Which is to 
return a bool to indicate success or failure and return the 
actual error through an out parameter. Any thing that is thrown 
need to implement the `Error` protocol. Which probably means that 
there is some for of type info used under the hood.

Zig uses a form of algebraic data type to return a value or an 
error. An error is represented as an error set, kind of like an 
enum. Zig provides syntax sugar on top this, which syntax looking 
very much like exceptions. The error handling in Zig looks pretty 
good, the only problem is that you can only throw error codes. 
It's not possible to provide any extra data with an error.

--
/Jacob Carlborg
Nov 26 2020
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:

 Rust has no exceptions (only `panic`, which aborts the current 
 thread), and instead opts to use algebraic data types along 
 with some light language support. Swift does something very 
 similar.


Worth mentioning that the default behaviour for Rust's `panic` is 
to unwind the stack.  This means that panics are recoverable 
errors in practice (e.g. the Tokio task-scheduling framework will 
gracefully handle panics inside individual tasks).

IIRC libraries can specify in their build config if they rely on 
the stack-unwinding behaviour, so that builds will fail if a 
downstream requests the abort option (or vice versa).  I believe 
though that even in the abort case, the parent thread may still 
be able to catch and recover from an aborted child thread.  See 
e.g.:
https://doc.rust-lang.org/nomicon/unwinding.html

So it's less that Rust has no exceptions, more that they don't 
_call_ them exceptions, they are not conceptualized as "this is 
allowed to fail", they don't distinguish different types of such 
error, and depending on the build config the circumstances in 
which they are recoverable are more or less constrained.
Nov 27 2020
parent reply IGotD- <nise nise.com> writes:
On Friday, 27 November 2020 at 12:52:37 UTC, Joseph Rushton 
Wakeling wrote:

 IIRC libraries can specify in their build config if they rely 
 on the stack-unwinding behaviour, so that builds will fail if a 
 downstream requests the abort option (or vice versa).  I 
 believe though that even in the abort case, the parent thread 
 may still be able to catch and recover from an aborted child 
 thread.  See e.g.:
 https://doc.rust-lang.org/nomicon/unwinding.html

 So it's less that Rust has no exceptions, more that they don't 
 _call_ them exceptions, they are not conceptualized as "this is 
 allowed to fail", they don't distinguish different types of 
 such error, and depending on the build config the circumstances 
 in which they are recoverable are more or less constrained.


Does this mean that Rust is dependent on libunwind despite its 
non exception like error handling?
Nov 27 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 19:33:32 UTC, IGotD- wrote:

 Does this mean that Rust is dependent on libunwind despite its 
 non exception like error handling?


Mixing languages is undefined behaviour... So, probably not?
Nov 27 2020
parent reply IGotD- <nise nise.com> writes:
On Friday, 27 November 2020 at 19:36:50 UTC, Ola Fosheim Grostad 
wrote:

 Mixing languages is undefined behaviour... So, probably not?


Unwinding isn't really connected to any language. It is a part of 
the CPU architecture runtime ABI even if it might be partially 
implemented in C or C++. Several languages glue to this ABI in 
order to implement their stack unwinding.
Nov 27 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 19:42:01 UTC, IGotD- wrote:

 On Friday, 27 November 2020 at 19:36:50 UTC, Ola Fosheim 
 Grostad wrote:

 Mixing languages is undefined behaviour... So, probably not?


 Unwinding isn't really connected to any language. It is a part 
 of the CPU architecture runtime ABI even if it might be 
 partially implemented in C or C++. Several languages glue to


Not portable. According to the docs, UB for Rust.
Nov 27 2020
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 19:42:01 UTC, IGotD- wrote:

 On Friday, 27 November 2020 at 19:36:50 UTC, Ola Fosheim 
 Grostad wrote:

 Mixing languages is undefined behaviour... So, probably not?


 Unwinding isn't really connected to any language. It is a part 
 of the CPU architecture runtime ABI even if it might be 
 partially implemented in C or C++. Several languages glue to 
 this ABI in order to implement their stack unwinding.


Just saw a pullrequest that does suggest that they use the 
regular libunwind as they argued about the license. But the docs 
still says that you need to catch errors at FFI boundaries.
Nov 28 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:

 On Saturday, 21 November 2020 at 23:05:19 UTC, IGotD- wrote:

 [...]


 This is well-trodden ground among D's competitors.

 Rust has no exceptions (only `panic`, which aborts the current 
 thread), and instead opts to use algebraic data types along 
 with some light language support. Swift does something very 
 similar.

 Go allows an optional return slot for an Error value that you 
 are not forced to check, as is typical for Go's approach of 
 choosing the worst possible option, but at least it's a slight 
 improvement on C. Get used to writing `if err != nil` every 
 other line.

 I think Nim actually does have exceptions.


Go's panic/recover mechanism are exceptions by another name.
Jan 05 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 21 November 2020 at 23:05:19 UTC, IGotD- wrote:

 I reacted to the comment of Walter Bright about exceptions in 
 the "Destroy All Memory Corruption" presentation. The point he 
 made that exceptions don't play well with compile time data 
 flow analysis. He also mentioned that he thinks that exception 
 will become obsolete in the future. Exceptions are used in many 
 languages today and even the newest ones so I can't see a trend 
 here.

 That raises the question what method is going to replace 
 exceptions in that case?
 Will D introduce an alternative method of error handler that 
 plays better with  live?


A (library-based) sum type used as error value, probably. That's 
what Rust does, except it also has language support for the 
concept. Because I personally don't like exceptions much, I have 
some experience from that approach (using TaggedAlgebraic). It 
feels somewhat cumbersome - Rust probably is better fit for that 

probably. `with` and `final switch` statements are useful in my 
experience. As is the possibility to 
`sumTypeVariable.visit!(...)`, but it has the downside that you 
always exit that statement the same way -you can't `break` or 
`goto` out.

Why I don't like exceptions? I feel I am making my functions less 
general when using them. For example, when parsing XML and 
encountering a syntax error, if I throw on the error I 
essentially declare that my function is only intended for 
generally sound XML -it isn't intended to count or list syntax 
errors in a text full of them. Errors in return codes are use 
case agnostic in this regard. Perhaps this is one of the reasons 
why Walter considers exceptions an aged concept.
Nov 25 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 04:41:57 UTC, Dukc wrote:

 less general when using them. For example, when parsing XML and 
 encountering a syntax error, if I throw on the error I 
 essentially declare that my function is only intended for 
 generally sound XML -it isn't intended to count or list syntax 
 errors in a text full of them. Errors in return codes are use 
 case agnostic in this regard. Perhaps this is one of the 
 reasons why Walter considers exceptions an aged concept.


Provide a templated object for custom error tracking and return a 
pointer to it wrapped as an exception.

That would be the most general approach.
Nov 25 2020