Re: [RFC] Exceptions in the engine

On 10/26/2013 01:18 PM, Rowan Collins wrote:

On 25/10/2013 20:41, Joe Watkins wrote:

If we really wanted to, we could fix all the code that throws the base Exception, making them throw specialized types, as they should

This seems a little contradictory when you're proposing an undifferentiated EngineException, where individual errors would need to be distinguished based on the message string. That's pretty much what throw Exception('Some message'); gives in userland. Besides which...

and include a compiler check that finds catch(Exception) blocks and complains, it shouldn't really be valid

I don't think "catch(Exception)" blocks exist as a partner to "throw Exception;" they exist to mark a boundary in code that you don't want any exceptions to cross, or where you want to log all exceptions in some bespoke way. They might be the last in a long string of catch() blocks attached to one try, like the default: label in a switch statement. They might also, as discussed wrt assertions/expectations, be in a unit testing framework.

They _should_ exist as a boundary, a last resort, if at all, but when they do exist they are no such boundary or last resort, they are normal catch blocks because the core throws the base Exception ... I'm just making the observation that it's not a very good idea to do that, doesn't take a lot to fix, has no bc issues and sets the right kind of standard. An EngineException is just that, an Exception from the Engine, that makes sense, an Exception coming from Date, doesn't make sense, that should be a DateException, it's not dependant on or descended from EngineException at all, it would just be better form if exceptions thrown from the core meant something so that catch all exception blocks when they are used are just as we all know they should be - a last resort, if present at all. Maybe emitting a warning is a bit pedantic ... Anyway, carry on with the discussion at hand, which is not about any of this at all, I was just saying it might be nice if we are to start using exceptions from core _as a policy_ to make good, as good as possible, our use of exceptions so far. Cheers Joe