Returning status messages

Question

There are methods in classes like "addSomething()". This can be successful or not successful. The status of the success can therefore be displayed with a boolean return value. But sometimes a method invocation can fail because of several reasons. "false" displays that, but only in a general manner. Sometimes the programmer wants to know the reason, why something failed. Is it, for this purpose, useful to provide an own report class that offers functionality like that?

public class Report {
    private final boolean success;
    private final String message;

    public Report(boolean success) {
        this.success = success;
        this.message = "empty message";

    }

    public Report(boolean success, String message) {
        this(success);
        this.message = message;
    }

    public boolean wasSuccessful() {
        return success;
    }

    public String getMessage() {
        return message;
    }
}

Then you can decide if you want to get a general success report with "wasSuccessful()" or if you also want to log the exact reason with "getMessage()".

But the problem is that exceptions dont offer an easy way to handle them in a "false-or-true" manner. With "false" or "true" you can build if-else statements more easy than with exceptions. You than could just write: If (object.method().wasSuccesful()) {doSomething) — , Jul 05 '19 at 12:29
@JonSkeet One should differentiate between expected and unexpected/uncontrollable errors. If errors and handling them is a fundamental part of your business logic do indeed use something more sophisticated than exceptions — roookeee, Jul 05 '19 at 12:29
Use boolean as return type for expected success and fails and throw an exception for unexpected fails. Adding messages is of no value, either use a good logging framwork where you can set log level per package/class or if you need more than true/false then create and use an enum for this — Joakim Danielson, Jul 05 '19 at 12:33
@roookeee: I agree that exceptions aren't *always* the right solution, but there's no indication that the OP is in the sort of situation where this is required. If they're reasonably new to Java, I'd encourage them to generally use exceptions for errors, then learn about where they're not appropriate over time when they've got the hang of the basics. — Jon Skeet, Jul 05 '19 at 12:37
@JonSkeet As it stands we have to make some pretty influential assumptions which take us nowhere, OP should clarify indeed. Agree with the rest you said — roookeee, Jul 05 '19 at 12:40

GhostCat · Accepted Answer · 2019-07-05T12:54:44.307

Is it, for this purpose, useful to provide an own report class that offers functionality like that?

"Usefulness" is subjective. If the above is what nicely solves your specific problem, then of course it is useful, and might be a good approach.

But in general, failure in Java is typically modelled by using exceptions of some wort.

Therefore, in many situations you simply go with void methods. As: the method just returning means: "all fine". Otherwise, if there was some problem, the method throws an exception at you.

Now, if on the other hand, you have situations where a method might pass or fail, and both outcomes are fully okay (for example if some method checks whether an optional parameter is present), then sure: your approach can be useful. You simply allow to add new Report objects for each method invocation that matters to you. And then whoever calls the method can create Report objects and add them to some context-specific ReportCollector.

But note: the real issue in my eyes: when you think about programmatically collecting (and using) such "progress" information, then message strings quickly turn into a problem. There is a good reason why people sometimes use numerical error ids: to enable programmatic handling of such situations. Strings only carry meaning for humans who read them.

Your code can't do much with strings. Remember: doing a contains("this") or contains("that") to determine how to react to error (messages) later on, that is a real anti pattern!

score 0 · Answer 2 · answered Jul 05 '19 at 12:32

0

You can try to use smth like Either pattern. It's used like Either<Report,Error> in each moment you will have either a valid report or an object with errors.

answered Jul 05 '19 at 12:32

dehasi

2,644
1
19
31

Returning status messages

2 Answers2