Drawbacks of exceptions being globally allocated

[Ali Çehreli]

On 8/15/21 2:10 AM, Alexandru Ermicioi wrote:

 >> This may be useful in some cases but in general, these colatteral
 >> exceptions don't carry much information and I don't think anybody
 >> looks at them. Usually, the first one is the one that explains the
 >> error case.

 > That is just an assumption.

Agreed but it's based on hands-on experience as well as exposure to 
these forums. :)

 > There could be designs where original
 > exception gets wrapped in another one

Wrapping is different and yes, it is useful. There have been cases where 
I hit a ConvException which only tells me a conversion failed. I do 
catch and augment it in outer contexts to saying something similar ot 
"That happened while doing this".

 > Regarding exception chaining, do you mean that it will automatically get
 > chained, even without explicitly passing it as constructor of wrapping
 > exception?

Yes. That's the functionality which isn't very useful because the 
collateral exceptions are usually because of the main one: Imagine the 
file system is full and a destructor cannot flush a file. The 
destructor's error is not interesting in this case.

class Main : Exception {
   this() {
     super("Main failed");
   }
}

class Dtor : Exception {
   this() {
     super("The destructor failed");
   }
}

struct S {
   ~this() {
     throw new Dtor();
   }
}

import std.stdio;

void main() {
   try {
     auto s = S();
     throw new Main();

   } catch (Exception exc) {
     stderr.writeln("Failed: ", exc.msg);
     stderr.writeln("This failed too: ", exc.next.msg);
     // (Of course, real code should stop when 'next' is null.)
   }
}

That output contains two automatically chained exceptions:

Failed: Main failed
This failed too: The destructor failed

Ali