Code case sharing for the construction and verification of Java and Ceylon objects

When converting Java code to Ceylon code, sometimes I encounter situations where some Java class constructors confuse validation and initialization. Let's use a simple but contrived code example to illustrate what I mean.

Some Bad Code

Consider the following Java class. (Dude, don't write code like this at home)

public class Period {
    private final Date startDate;
    private final Date endDate;
    //returns null if the given String
    //does not represent a valid Date
    private Date parseDate(String date) {
       ...
    }
    public Period(String start, String end) {
        startDate = parseDate(start);
        endDate = parseDate(end);
    }
    public boolean isValid() {
        return startDate!=null && endDate!=null;
    }
    public Date getStartDate() {
        if (startDate==null) 
            throw new IllegalStateException();
        return startDate;
    }
    public Date getEndDate() {
        if (endDate==null)
            throw new IllegalStateException();
        return endDate;
    }
}

Hey, I've warned before, it's artificial. However, it's actually not uncommon to find something like this in real Java code.

The problem here is that even if the validation of the input parameter (in the hidden parseDate() method) fails, we still get an instance of Period. But the Period we obtained is not a "valid" state. Strictly speaking, what do I mean?

Well, I would say that an object is in an inactive state if it cannot meaningfully respond to common operations. In this example, getStartDate() and getEndDate() will throw an IllegalStateException, which is a situation that I don't think "makes sense".

Looking at this example from the other side, when designing Period, we have a failure of type

security. Unchecked exceptions represent a "hole" in the type system. Therefore, a better type-safe design for Period would be one that does not use unchecked exceptions—which in this case means not throwing an IllegalStateException.

(Actually, in real code, I'm more likely to encounter a getStartDate() method that doesn't check for null, which results in a NullPointerException after this line of code, which is even worse.)

We can easily convert the above Period class into a Ceylon-style class:

shared class Period(String start, String end) {
    //returns null if the given String
    //does not represent a valid Date
    Date? parseDate(String date) => ... ;
    value maybeStartDate = parseDate(start);
    value maybeEndDate = parseDate(end);
    shared Boolean valid
        => maybeStartDate exists 
        && maybeEndDate exists;
    shared Date startDate {
        assert (exists maybeStartDate);
        return maybeStartDate;
    }
    shared Date endDate {
        assert (exists maybeEndDate);
        return maybeEndDate;
    }
}

Of course, this code will also encounter the same problems as the original Java code. The two assert symbols scream at us that there is a problem in the type safety of the code.

Making Java code better

How can we improve this code in Java? Well, here's an example where Java's much-maligned checked exceptions can be a very reasonable solution! We can slightly modify the Period to throw a checked exception from its constructor:

public class Period {
    private final Date startDate;
    private final Date endDate;
    //throws if the given String
    //does not represent a valid Date
    private Date parseDate(String date)
            throws DateFormatException {
       ...
    }
    public Period(String start, String end) 
            throws DateFormatException {
        startDate = parseDate(start);
        endDate = parseDate(end);
    }
    public Date getStartDate() {
        return startDate;
    }
    public Date getEndDate() {
        return endDate;
    }
}

Now, using this solution, we will not get a Period in an inactive state, instantiating it The code of Period will be handled by the compiler to handle invalid input situations, and it will catch a DateFormatException exception.

try {
    Period p = new Period(start, end);
    ...
}
catch (DateFormatException dfe) {
    ...
}

This is a nice, perfect, and correct use of checked exceptions. Unfortunately, I rarely see Java code using checked exceptions like the above.

Making Ceylon Code Better

So what about Ceylon? Ceylon has no checked exceptions, so we need to find a different solution. Typically, in situations where calling a

function in Java would throw a checked exception, Ceylon would call the function to return a union type. Since, a class initializer does not return any type other than the class itself, we need to extract some mixed initialization/validation logic into a factory function.

//returns DateFormatError if the given 
//String does not represent a valid Date
Date|DateFormatError parseDate(String date) => ... ;
shared Period|DateFormatError parsePeriod
        (String start, String end) {
    value startDate = parseDate(start);
    if (is DateFormatError startDate) {
        return startDate;
    }
    value endDate = parseDate(end);
    if (is DateFormatError endDate)  {
        return endDate;
    }
    return Period(startDate, endDate);
}
shared class Period(startDate, endDate) {
    shared Date startDate;
    shared Date endDate;
}

Depending on the type system, the caller is obligated to handle DateFormatError:

value p = parsePeriod(start, end);
if (is DateFormatError p) {
    ...
}
else {
    ...
}

Alternatively, if we don't care about the actual issues with the given date format (which is possible, assuming we work The initialization code loses that information), we can use Null instead DateFormatError:

//returns null if the given String 
//does not represent a valid Date
Date? parseDate(String date) => ... ;
shared Period? parsePeriod(String start, String end)
    => if (exists startDate = parseDate(start), 
           exists endDate = parseDate(end))
       then Period(startDate, endDate)
       else null;
shared class Period(startDate, endDate) {
    shared Date startDate;
    shared Date endDate;
}

The approach using the factory function is excellent, to say the least, because generally speaking it has Better isolation. This is especially useful in Ceylon, where the compiler adds some very strict restrictions on the object initialization logic to ensure that all fields of an object are assigned only once.

The above is the detailed content of Code case sharing for the construction and verification of Java and Ceylon objects. For more information, please follow other related articles on the PHP Chinese website!