qdzo / ceylon-config Goto Github PK

Assertion errors in Ceylon indicate that something that should never happen in a correctly‐written program has happened; they are not meant to actually be caught. Catching them is not only bad practice, but it’s also inherently wrong by the definition of assertion errors.

Additionally, assertions are meant to check for developer input, and not user input. An uncaught assertion error implies that there is a bug in the program, and not that the user didn’t provide a necessary environment variable.

The correct thing to do would be to have your optional methods potentially return null, and have your existence‐asserting methods check for their result and throw something that is not an AssertionError in case they are null so that it can be caught by the developer for them to display a proper error message.

That is, instead of writing the following:

shared String getString(Object key){
    assert(exists val = get(key));
    return val;
}

shared String? getStringOrNull(Object key){
    try {
        return getString(key);
    } catch(AssertionError ae) {
        return null;
    }
}

it is, by the definition of AssertionError, objectively more correct to write the following:

shared String? getStringOrNull(Object key) => this[key];

shared String getString(Object key)
{
    if(exists string = getStringOrNull(key))
    {
        return(string);
    }
    else
    {
        throw(Something());
    }
}

Perhaps more subjectively, I really don’t think these type‐unsafe non‐OrNull methods are actually a good practice in Ceylon. Ideally you don’t want to give the user of your library the confidence that these values will exist, and instead, you should require them to actually act upon the possibility of them not existing.