Re: [Arianne-devel] Hi, from a stranger

[Mike H. <ar...@pe...>]

----- Original Message -----
From: "SkyFlash" <sky...@ch...>
To: <ari...@li...>
Sent: Monday, October 28, 2002 12:25 AM
Subject: AW: [Arianne-devel] Hi, from a stranger


> > I think that's exactly what we need.  I wish people would ask
> > me such questions about my code more often.  We all make
> > stupid design and coding decisions and especially C++ newbies
> > won't always know a lot of these things.  As long as comments
> > like this are constructive then the inexperienced guys can
> > learn from the gurus and the codebase quality improves tremendously.
>
> Well yes thats correct.
>
> > I had a discussion with SkyFlash a couple of weeks ago about
> > using exceptions and he is completely against them since they
> > cause so many problems in the code.  But if people knew how
> > to use them properly and threw
> > *useful* exceptions with good logging info it would make
> > things a lot easier.
>
> Basicly I am against exceptions for some reasons...
> I am only talking about the server though, for the clients its
> different.
>
> First off the exceptions are used even where a function return could
> supply
> error information without throwing an exception. Thats real bad. I just
> don't
> see why we would throw an exception that POSSIBLY could make the server
> crash,
> when we can supply the error in a normal manner by using function return
> values.
> That way, we can also handle the error right where it happened and not
> cause the
> function to just exit and get catched like 5 levels higher. (Which was
> actually
> happening)
>
But that's the whole reason exceptions were invented.  Using return values
relies on the client code to *always* test returns.  None of us can
guarantee to live up to that.  Throwing an exception gives you that
guarantee.  IMO it's better to have defined bahaviour (crash with unhandled
exception which should contain enough info to uniquely identify where the
problem occurred) than undefined behaviour when returns aren't checked
properly.  As for catching them, you can handle the exception wherever you
want.  If a bit of client code can't do anything useful with the knowledge
then it just completely ignores it and eventually a caller will be able to
act appropriately (or you crash out if nothing handles it).  If completely
unhandled exceptions causing a crash are a problem then just put a try-catch
round the code in main and grab everything that could possibly go wrong in
there by catch(...)

> Second, exceptions are not portable. They dont work everywhere, which
> for example
> you can also read in the Mozilla porting faq...
>
I have no experience here so I'll go with you on this.  What are the
problems exactly and can't they be worked around though?

> Third, when an application crashes because of an exception, sometimes on
> windows the
> source cannot be traced down. I had the exception crash my whole comp,
> my compiler,
> sometimes just the program, but many times the not catched exception
> (which is a bad
> thing anyway) didnt even give me access to the traceback, so I had no
> idea where it
> crashed, why it crashed, or what to do against it. I dont know about
> linux, but on
> windows those exceptions tend to fuck up the whole compiler environment
>
Again, if you have a catch all handler in main() then you won't ever see
this kind of problem.

> I prefer to use function returns whereever possible, and when using
> exceptions, to
> catch them right away! I dont know how much of the exception code needs
> fixing, but
> I guess its a lot.
>
> I basicly dont want the server to throw ANY exception for non-critical
> stuff. If he doesnt
> find the Worldfile, he COULD throw an exception.. but he wont cause i
> got it with function
> returns. But if some Object is not found, I dont wanna see an "Object
> not found" exception.
> Ok, he didnt find it. It may be gone. Get over it, dont make the server
> crash for it...
> even if the crash may be catched by a catch statement somewhere. Someone
> may delete the
> statement, and next time we are in for a server crash.
> The Server was even throwing exceptions when an attribute was not found!
> Thats not how it works.
> If the attribute is not found it will now return an empty string.
>
> For me, throwing exceptions is a way to crash the server. I dont want
> code that crashes the
> server. Its bad. Now it may be catched. Month later it may be a crash
> bug.
>
Well, I don't agree with this.  I think using returns is just building on
sand.  You can introduce lots of subtle bugs this way.  If you have a good
exception handling strategy in place it should be much more stable.  The C++
standards guys weren't stupid when they designed exceptions.

> And for clients, well, if they crash, I dont care. Tough luck. We fix
> it, and its fine.
>
> Now imagine you got a game server with 1000 players and it crashes.
> Those exceptions will
> not trigger the WorldSave function if they arent catched correctly. :)
They will if your top level handler calls WorldSave.

Anyway, just my 2c worth.

MikeH