On 9/20/18 11:33 AM, Adam D. Ruppe wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven Schveighoffer
wrote:
As Andrei says -- Destroy!
Nah, I agree. Actually, I'm of the opinion that string error messages in
exceptions ought to be considered harmful: you shouldn't be doing
strings at all. All the useful information should be in the type - the
class name and the members with details.
Well, defining a new class can sometimes be a mild hassle... but for
really common ones, we really should just do it, and other ones can be
done as templated classes or templated factory functions that define a
new class right there and then.
http://arsdnet.net/dcode/exception.d
That's the proof-of-concept I wrote for this years ago, go to the bottom
of the file for the usage example. It uses a reflection mixin to make
writing the new classes easy, and I even wrote an enforce thing that can
add more info by creating a subclass that stores arguments to functions
so it can print it all (assuming they are sane to copy like strings or
value things lol)
enforce!fopen("nofile.txt".ptr, "rb".ptr);
MyExceptionBase@exception.d(38): fopen call failed
filename = nofile.txt
mode = rb
----------------
Awesome! This is just what I was thinking of. In fact, I did something
similar locally since I needed to know what the slice parameters that
were failing were. I still had to trick the @nogc to get around the "new
Exception" piece.
The printMembers thing is nice. I think for druntime/phobos, however, we
should have a base that just calls a virtual function with the idea that
the message is printed, and then a further-derived type could do the
printMembers thing if that's what you want.
-Steve
