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