Disable C++ exceptions

Disable C++ exceptions

1) Drop exception handling around scm_boot_guile

Doing this at the end of main() is pointless.

2) Disable exception handling code

We don't throw in LilyPond and it's only bloating the executable:
before: 192,586,512B
after:  166,845,952B (-13.3%)

This might also have a positive effect on the build time as well as
performance during runtime, but I didn't try to measure that for now.

[lemzwerg, 2020-01-27 20:30:36]

LGTM

[Dan Eble, 2020-01-27 21:05:27]

> 1) Drop exception handling around scm_boot_guile
> Doing this at the end of main() is pointless.

Agreed.  (It should have been caught by reference anyway.)

> 2) Disable exception handling code
> We don't throw in LilyPond and it's only bloating the executable:
> before: 192,586,512B
> after:  166,845,952B (-13.3%)

A. Do we care that much about about 30 MB?  Is someone complaining?
B. The standard library may throw for various reasons.

> This might also have a positive effect on the build time

I have no experience with this.

> as well as performance during runtime

Not likely.  The cost is about zero until one is thrown.  I've worked on
high-availability, high-performance network packet processing products where we
used exceptions to good effect.

I don't have a better reason to oppose disabling exceptions than that I've found
them useful in other projects, so I'll say LGTM; but I think we could offer
posterity a better justification than 30 MB and maybe build time.

To me, the most convincing argument for disabling exceptions (which in g++ turns
them into abort(), IIUC; I'm not sure about clang) would be that you don't want
LilyPond contributors to have to write exception-safe code.  It's not natural
for C programmers coming into C++.  Also, I'm sure you've already got some.

[hahnjo, 2020-01-28 17:36:16]

On 2020/01/27 21:05:27, Dan Eble wrote:
> > 1) Drop exception handling around scm_boot_guile
> > Doing this at the end of main() is pointless.
> 
> Agreed.  (It should have been caught by reference anyway.)
> 
> > 2) Disable exception handling code
> > We don't throw in LilyPond and it's only bloating the executable:
> > before: 192,586,512B
> > after:  166,845,952B (-13.3%)
> 
> A. Do we care that much about about 30 MB?  Is someone complaining?

Yes, I care. Why waste space if we don't have to?

> B. The standard library may throw for various reasons.

As far as I know, it calls abort() instead of raising exceptions when compiled
with -fno-exceptions. Even if not, libc will catch the exception and show the
result of e.what().

> > This might also have a positive effect on the build time
> 
> I have no experience with this.

Short unscientific experiment on my otherwise idle laptop from 2016 (make -j4):
before:
real    6m34,192s
user    20m12,628s
sys     1m18,162s

after:
real    6m12,393s
user    18m48,599s
sys     1m15,815s

> > as well as performance during runtime
> 
> Not likely.  The cost is about zero until one is thrown.  I've worked on
> high-availability, high-performance network packet processing products where
we
> used exceptions to good effect.

Agreed with the generated exception handling code on Linux, I might have
confused with the older version from Windows. But even they have a low overhead
nowadays.

> I don't have a better reason to oppose disabling exceptions than that I've
found
> them useful in other projects, so I'll say LGTM; but I think we could offer
> posterity a better justification than 30 MB and maybe build time.
> 
> To me, the most convincing argument for disabling exceptions (which in g++
turns
> them into abort(), IIUC; I'm not sure about clang) would be that you don't
want
> LilyPond contributors to have to write exception-safe code.  It's not natural
> for C programmers coming into C++.  Also, I'm sure you've already got some.

Just my opinion: I think many projects work well without exceptions, with GCC
and LLVM being two large ones that I'm used to. At the moment, I don't see a
valid use case for exceptions in LilyPond, but I haven't seen all of the code
yet. If exceptions prove helpful in the future, we can certainly think about
switching them back on.

[hanwenn, 2020-01-28 22:28:02]

LGTM

I don't think there is any chance of ever using exceptions in LilyPond, because
we can't mix them with the GUILE call stack.

[haberg-1_telia.com, 2020-01-29 00:20:07]

> On 28 Jan 2020, at 23:28, hanwenn@gmail.com wrote:
> 
> I don't think there is any chance of ever using exceptions in LilyPond,
> because we can't mix them with the GUILE call stack.

One can combine C++ and Guile exceptions, by converting back and forth between
them. Even though GCC admits throwing C++ exceptions through a C stack by some
option, somebody mentioned there are complications with that, and better
avoided.