Java - How to represent the result of an operation

Question 1

Introduction

In my Java application, I need to represent the result of an operation. This can either be OK or ERROR + an error message.

Background

I have a class to verify the integrity of a directory (e.g. to check that a few conditions hold). If it finds out the directory is corrupted, it should return a description of the error, such as:

Unexpected file - [filename].
Unexpected number of files - expected [X], actual [Y].

The callers of the class don't know anything about the directory and the conditions. They are only interested to know if the directory is OK or not, and in that case, to get an appropriate error message.

The Result class was intended as a way to transmit the results of the verification.

I chose not to throw exceptions as (to me) that seemed more convenient for reporting errors in the verification process. It seemed inappropriate to intermix those two situations (e.g. the directory was found invalid vs. an error occurred while verifying the directory).

The current solution

I have so far been able to come up with the following class.

public class Result
{
 private static enum State { OK, ERROR };
 private State state;
 private String errorMessage;
 private Result(State state, String errorMessage)
 {
 this.state = state;
 this.errorMessage = errorMessage;
 }
 public static Result ok()
 {
 return new Result(State.OK, null);
 }
 public static Result error(String errorMessage)
 {
 return new Result(State.ERROR, errorMessage);
 }
 public boolean isOK()
 {
 return (this.state == State.OK);
 }
 public String getErrorMessage()
 {
 return errorMessage;
 }
}

The client code then looks like this:

Result result = Result.ok();
Result result = Result.error("Could not ...");
if (result.isOK())
 ...
else
{
 String errorMessage = result.getErrorMessage();
 ...
}

This has the benefit that when creating a result, the client only has to deal with error messages in case of an error.

On the other hand, the API does not prevent the client code to ask for an error message in case of an OK result. That does not feel right.

I also don't like the way the information about valid states (OK/ERROR) gets duplicated into:

the internal enumeration,
the public static methods.

What do you think about my implementation? How would you design the class?

Question 2

Are you sure you even need such a class? Why not stick with exceptions?

Question 3

I added some background information and elaborated more on that decision. I'm not that sure about it anymore, though. Firstly, I'm not sure that the verification process itself might (in my specific case) fail. Secondly, I could use two different exception types to mark the distinction (and catch and process them separately). But I have a feeling that those two (e.g. verification failure vs. a negative response) are different concepts and should be handled differently. I mean, it is not an error in the verification process if a directory is found invalid.

Question 4

Thanks for the clarifying edit, that makes a lot of sense to me.

Question 5

"the API does not prevent the client code to ask for an error message in case of an OK result" but is that really a problem? Optional does also not prevent a client from querying the value if non is present, instead it throws an error as it is basically a "misuse".

Question 6

After Java 17, you can perhaps even use sealed classes for this: https://openjdk.org/jeps/409

Something like:

sealed interface IOResult permits Ok, Err {
 record Ok() implements IOResult {}
 record Err(IOException error) implements IOResult {}
}
class FileManager {
 IOResult writeFile(Path path, String contents) {
 try {
 IOUtils.writeFile(path, contents);
 return new Ok();
 } catch (IOException e) {
 return new Err(e);
 }
 }
}

Then you can do Rust-y stuff like:

IOResult res = fileManager.writeFile(path, contents);
return switch (res) {
 case Ok -> ???;
 case Err(var error) -> ???;
}

Question 7

Your code looks very much like Rust! doc.rust-lang.org/std/result/enum.Result.html

Question 8

I do not know the exact requirements, but two simple approaches would be:

Just return a String as result. This can either be null or empty (if everything is ok) or the error message (if something is wrong).
Throw an exception

(Other then that: I would try to find a better name for the factory methods. The meaning of the current names is not really clear.)

edit after original post was changed:

If you do not need a general solution or anything special, I would keep the simple way and return a String. KISS principle.

If you want to make it fancy, I would continue with your approach, only slightly modified:

public class DirectoryChecker
{
 private String errorMessage;
 //or private List<String/anything else> errors;
 public static Result ok()
 {
 return new Result(State.OK, null);
 }
 public boolean isThereAnyProblem()
 {
 // check if everything is ok. Set error if not.
 // if the check should be done only once, add a member variable to keep the state
 }
 public String /* or anything else */ getErrorMessage/*s*/()
 {
 return errorMessage /*or anything else*/;
 }
}

Explanations:

Some factory method will create an instance of this class. The caller can do: if(directoryChecker.isThereAnyProblem()) { get and handle error }
I do not think you need the enum. It represents a state of the internal state. And you only need ok/not ok as far as I got it.
As you see this is hardly the same as the String approach, you just wrap an additional class around it.

Side note: You could name the check method isEverythingOk, but personally I prefer this flow of code:

if (something happened)
 { handle it }
go on with normal flow

instead of

if (everything is ok)
 { do normal things }
else
 { handle it }
go on with normal(?) code or other code(?)

About exceptions: I would not use them in this case, it makes life only more complex.

Question 9

I updated the question and described why I did not choose exceptions to transmit the error message.

Question 10

@DušanRychnovský I have updated my post to reflect your changes

Question 11

@tb- I don't think that simply returning a string would be a great idea. I feel better when the domain concepts have their own class and I don't have to guess what is the meaning of a string

Question 12

I'd change your enum State, like this:

enum State
{
 OK(null),
 COULDNT_LOAD("Error: Could not load file: %s."),
 COULDNT_PARSE("Error: Could not parse contents of file %s."),
 UNEXPECTED_NUM_FILES("Error: Unexpected number of files - expected %d, actual %d.");
 String message;
 State(String message)
 {
 this.message = message;
 }
 void setReplacements(Object... replacements)
 {
 if(this.message != null)
 {
 this.message = new Formatter().format(this.message, replacements).toString();
 }
 }
}

Then you can have your validation method return a state, and you can do your checking block after, like this:

File fileITriedToLoad = new File("/usr/file.java");
State result = State.COULDNT_LOAD;
result.setReplacements(fileITriedToLoad.getAbsolutePath());
if(result != State.OK)
{
 System.out.println(result.message);
}

And you can delete the rest of your Result class.

Edit: Using the new setReplacements() method would then allow you to add pieces of text at the specified points in your message, so your validation method that returns a State would use it as follows:

State state = State.UNEXPECTED_NUM_FILES;
state.setReplacements(1, 3);

And then printing the state.message will produce:

Error: Unexpected number of files - expected 1, actual 3.

Question 13

It seems that in this case, the error message would always be like "Okay" or "Error". That's not what I need. I need it to be either undefined (if the state is OK), or a custom error message, like "Could not open file XXX." (if the state is ERROR). Moreover, multiple error messages should be expressible (e.g. "Could not open file XXX.", "Could not parse contents of file XXX.", etc.).

Question 14

@DušanRychnovský Well then, if you know what file they tried to load, see my edits.

Question 15

@DušanRychnovský And to pre-empt the next question: if you don't know the file, wrap the file and Status into a ValidatedFile class with a getState() and getFile() method.

Question 16

I need a more general solution. I updated the question to make this more apparent. I admit I have not made it clear in my previous comment that not all error messages are related to a single file.

Question 17

@DušanRychnovský Edited accordingly :)

Question 18

If you don't want to use exceptions you should know that in OOP there is a lot of ways to implement the fact that some object belongs to some specific class. It can be either some enum that enumerates all possible domains or in case of OOP languages it can be class.

So in case of Java (again if you don't want exceptions by some reason) you can use:

class Result
{
 public static final Result ok = new Result(); // I'm not sure this is correct in terms of Java
}
class Failure extends Result
{
 public final String errorMessage;
 public Faliure(String message)
 { this.errorMessage = message; }
}
if (result instanceof Failure)
{
 // do something
}

Question 19

I like this idea. The only (subtle) drawback I see is that you have to explicitly cast the result to a Failure in order to obtain the error message. You also have to know the implementation details (e.g. that there is a class hierarchy) to be able to distinguish between an OK and an ERROR state.

Question 20

@DušanRychnovský, you need to know that as well in case of enum and others. You can tear off need of hierarchy by using interfaces. You can add continuation behavior and make Result to provide Result RunWithSuccess(/* some action representation */) which will do nothing but return this for Failure and result of action execution for ok.

Question 21

@DušanRychnovský if you don't have a hierarchy like that you are going to have an ok result coming with an error message and that does not make too much sense to me

Question 22

@mariosangiorgio exactly - that's one of the drawbacks I see with my own solution and one of the reasons why I like this one.

Question 23

The problem with this is that it is implied that OK is a Result, and so a Result is OK. It would be better to have a another class to represent OK.

Question 24

I am convinced that for some use-cases more than one error may happen, that are more or less separate cases. And some can be dealt with differenty. All on a case basis.

And no error messages means okay!

public class Result
{
 private Set<String> errorMessages;
 public boolean isOK()
 {
 return errorMessages.isEmpty();
 }
 public Set<String> getErrorMessages()
 {
 return errorMessages;
 }

Error codes might be considered too, but at least this diversification allows errors to flow in from different sources while retaining information on all error cases.

The errors for "unexpected file" and "unexpected number of files" are likely to stem from different locations. In the case of exceptions thrown and caught, some collection or arbitration of errors is needed anyway.

Notice the single Result type for the all-okay state has a disarming getErrorMessages() - to know: the empty set.

Mandeep Mandeep 711 silver badge1 bronze badge · Answer 1 · 2025-02-21 10:14:32Z

After Java 17, you can perhaps even use sealed classes for this: https://openjdk.org/jeps/409

Something like:

sealed interface IOResult permits Ok, Err {
 record Ok() implements IOResult {}
 record Err(IOException error) implements IOResult {}
}
class FileManager {
 IOResult writeFile(Path path, String contents) {
 try {
 IOUtils.writeFile(path, contents);
 return new Ok();
 } catch (IOException e) {
 return new Err(e);
 }
 }
}

Then you can do Rust-y stuff like:

IOResult res = fileManager.writeFile(path, contents);
return switch (res) {
 case Ok -> ???;
 case Err(var error) -> ???;
}

Your code looks very much like Rust! doc.rust-lang.org/std/result/enum.Result.html

tb- tb- 2,28312 silver badges15 bronze badges · Answer 2 · 2013-01-08 18:21:59Z

I do not know the exact requirements, but two simple approaches would be:

Just return a String as result. This can either be null or empty (if everything is ok) or the error message (if something is wrong).
Throw an exception

(Other then that: I would try to find a better name for the factory methods. The meaning of the current names is not really clear.)

edit after original post was changed:

If you do not need a general solution or anything special, I would keep the simple way and return a String. KISS principle.

If you want to make it fancy, I would continue with your approach, only slightly modified:

public class DirectoryChecker
{
 private String errorMessage;
 //or private List<String/anything else> errors;
 public static Result ok()
 {
 return new Result(State.OK, null);
 }
 public boolean isThereAnyProblem()
 {
 // check if everything is ok. Set error if not.
 // if the check should be done only once, add a member variable to keep the state
 }
 public String /* or anything else */ getErrorMessage/*s*/()
 {
 return errorMessage /*or anything else*/;
 }
}

Explanations:

Some factory method will create an instance of this class. The caller can do: if(directoryChecker.isThereAnyProblem()) { get and handle error }
I do not think you need the enum. It represents a state of the internal state. And you only need ok/not ok as far as I got it.
As you see this is hardly the same as the String approach, you just wrap an additional class around it.

Side note: You could name the check method isEverythingOk, but personally I prefer this flow of code:

if (something happened)
 { handle it }
go on with normal flow

instead of

if (everything is ok)
 { do normal things }
else
 { handle it }
go on with normal(?) code or other code(?)

About exceptions: I would not use them in this case, it makes life only more complex.

I updated the question and described why I did not choose exceptions to transmit the error message.
@DušanRychnovský I have updated my post to reflect your changes
@tb- I don't think that simply returning a string would be a great idea. I feel better when the domain concepts have their own class and I don't have to guess what is the meaning of a string

MrLore MrLore 1,3789 silver badges16 bronze badges · Answer 3 · 2013-01-08 20:08:28Z

I'd change your enum State, like this:

enum State
{
 OK(null),
 COULDNT_LOAD("Error: Could not load file: %s."),
 COULDNT_PARSE("Error: Could not parse contents of file %s."),
 UNEXPECTED_NUM_FILES("Error: Unexpected number of files - expected %d, actual %d.");
 String message;
 State(String message)
 {
 this.message = message;
 }
 void setReplacements(Object... replacements)
 {
 if(this.message != null)
 {
 this.message = new Formatter().format(this.message, replacements).toString();
 }
 }
}

Then you can have your validation method return a state, and you can do your checking block after, like this:

File fileITriedToLoad = new File("/usr/file.java");
State result = State.COULDNT_LOAD;
result.setReplacements(fileITriedToLoad.getAbsolutePath());
if(result != State.OK)
{
 System.out.println(result.message);
}

And you can delete the rest of your Result class.

Edit: Using the new setReplacements() method would then allow you to add pieces of text at the specified points in your message, so your validation method that returns a State would use it as follows:

State state = State.UNEXPECTED_NUM_FILES;
state.setReplacements(1, 3);

And then printing the state.message will produce:

Error: Unexpected number of files - expected 1, actual 3.

It seems that in this case, the error message would always be like "Okay" or "Error". That's not what I need. I need it to be either undefined (if the state is OK), or a custom error message, like "Could not open file XXX." (if the state is ERROR). Moreover, multiple error messages should be expressible (e.g. "Could not open file XXX.", "Could not parse contents of file XXX.", etc.).
@DušanRychnovský Well then, if you know what file they tried to load, see my edits.
@DušanRychnovský And to pre-empt the next question: if you don't know the file, wrap the file and Status into a ValidatedFile class with a getState() and getFile() method.
I need a more general solution. I updated the question to make this more apparent. I admit I have not made it clear in my previous comment that not all error messages are related to a single file.

ony ony 6393 silver badges5 bronze badges · Answer 4 · 2013-01-08 21:52:34Z

3

\$\begingroup\$

If you don't want to use exceptions you should know that in OOP there is a lot of ways to implement the fact that some object belongs to some specific class. It can be either some enum that enumerates all possible domains or in case of OOP languages it can be class.

So in case of Java (again if you don't want exceptions by some reason) you can use:

class Result
{
 public static final Result ok = new Result(); // I'm not sure this is correct in terms of Java
}
class Failure extends Result
{
 public final String errorMessage;
 public Faliure(String message)
 { this.errorMessage = message; }
}
if (result instanceof Failure)
{
 // do something
}

Share

edited Jul 9, 2013 at 16:31

Anirban Nag 'tintinmj''s user avatar

Anirban Nag 'tintinmj'

2,01715 silver badges33 bronze badges

answered Jan 8, 2013 at 21:52

ony's user avatar

ony ony

6393 silver badges5 bronze badges

\$\endgroup\$

6

1

\$\begingroup\$ I like this idea. The only (subtle) drawback I see is that you have to explicitly cast the result to a Failure in order to obtain the error message. You also have to know the implementation details (e.g. that there is a class hierarchy) to be able to distinguish between an OK and an ERROR state. \$\endgroup\$

Dušan Rychnovský
– Dušan Rychnovský

2013年01月09日 09:22:45 +00:00
Commented Jan 9, 2013 at 9:22
\$\begingroup\$ @DušanRychnovský, you need to know that as well in case of enum and others. You can tear off need of hierarchy by using interfaces. You can add continuation behavior and make Result to provide Result RunWithSuccess(/* some action representation */) which will do nothing but return this for Failure and result of action execution for ok. \$\endgroup\$

ony
– ony

2013年01月09日 10:01:48 +00:00
Commented Jan 9, 2013 at 10:01
\$\begingroup\$ @DušanRychnovský if you don't have a hierarchy like that you are going to have an ok result coming with an error message and that does not make too much sense to me \$\endgroup\$

mariosangiorgio
– mariosangiorgio

2013年01月09日 13:57:06 +00:00
Commented Jan 9, 2013 at 13:57
\$\begingroup\$ @mariosangiorgio exactly - that's one of the drawbacks I see with my own solution and one of the reasons why I like this one. \$\endgroup\$

Dušan Rychnovský
– Dušan Rychnovský

2013年01月09日 14:33:29 +00:00
Commented Jan 9, 2013 at 14:33
\$\begingroup\$ The problem with this is that it is implied that OK is a Result, and so a Result is OK. It would be better to have a another class to represent OK. \$\endgroup\$

Bobby
– Bobby

2025年02月21日 10:47:48 +00:00
Commented Feb 21 at 10:47

| Show 1 more comment

Joop Eggen Joop Eggen 4,52115 silver badges19 bronze badges · Answer 5 · 2025-02-27 14:48:19Z

I am convinced that for some use-cases more than one error may happen, that are more or less separate cases. And some can be dealt with differenty. All on a case basis.

And no error messages means okay!

public class Result
{
 private Set<String> errorMessages;
 public boolean isOK()
 {
 return errorMessages.isEmpty();
 }
 public Set<String> getErrorMessages()
 {
 return errorMessages;
 }

Error codes might be considered too, but at least this diversification allows errors to flow in from different sources while retaining information on all error cases.

The errors for "unexpected file" and "unexpected number of files" are likely to stem from different locations. In the case of exceptions thrown and caught, some collection or arbitration of errors is needed anyway.

Notice the single Result type for the all-okay state has a disarming getErrorMessages() - to know: the empty set.

Stack Exchange Network

Java - How to represent the result of an operation

Introduction

Background

The current solution

What do you think about my implementation? How would you design the class?

5 Answers 5

Your Answer

Sign up or log in

Post as a guest

Post as a guest

Hot Network Questions

Java - How to represent the result of an operation

Introduction

Background

The current solution

What do you think about my implementation? How would you design the class?

5 Answers 5

Your Answer

Sign up or log in

Post as a guest

Post as a guest

Related

Hot Network Questions