Re: Compilation fixes for GUILE 2.2 (issue 571430046 by address@hidden)

[jonas . hahnfeld]

On 2020/01/26 14:37:44, dak wrote:
> https://codereview.appspot.com/571430046/diff/551390052/lily/main.cc
> File lily/main.cc (right):
> 
>
https://codereview.appspot.com/571430046/diff/551390052/lily/main.cc#newcode830
> lily/main.cc:830: catch (std::exception e)
> On 2020/01/26 14:24:02, hahnjo wrote:
> > On 2020/01/26 14:18:20, hanwenn wrote:
> > > On 2020/01/26 14:13:58, hahnjo wrote:
> > > > Is it really throwing C++ exceptions? If this means to catch any
from
> > > LilyPond,
> > > > I don't think we throw any and I have a patch locally which
compiles all
> of
> > > > LilyPond with -fno-exceptions to reduce binary size.
> > > 
> > > I think the C++ library might throw exceptions if you're unlucky.
> > > 
> > > I prefer we discuss getting rid of this code some other time. I
just want it
> > to
> > > compile.
> > 
> > Even if there is an exception, catching it at the end of main is no
different
> > from letting it unhandled. So I'm all for removing this special case
now. Or
> did
> > you actually hit it?
> 
> I'd rather we get an error message for bad_alloc which certainly can
happen.

You get this by default, suppose:

int main(int argc, char *argv[]) {
  new double[1000000000];
  return 0;
}

 $ g++ test.cpp
 $ ulimit -v 16384
 $ ./a.out 
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

Maybe I'm missing where the code would give you a better message?

https://codereview.appspot.com/571430046/