0

We have the following scenario in our company:

There are some business objects which have business rules associated with them. One of these objects, Person, has the following rules:

  • A Person must have a name (that is in coding terms not null, nor empty)
  • A Person's name mustn't consist solely of spaces and/or tabs

The business object has in its constructor a parameter for name, which uses a non-nullable type to receive the name. In similar fashion there's a property which stores the name as a non nullable type.

In the constructor an exception (MyException) is thrown when the name is empty after trimming the spaces and/or tabs.

There's also a backend which deals with these objects using REST api through JSON

Right now we are using a library (Jackson) to parse JSON data received in our backend. We have specified in our DTOs that the field for the name can't be null or be missing from the JSON object. In case of deserializing a JSON object with a missing/null name field the library throws an exception.

If a Person received in the backend throws MyException then the backend converts that exception into an detailed JSON message to be sent to the client.

But if the received JSON of a Person doesn't have the field 'name' or is null we let the library throws its own Exception and that is the error presented to the client.

The question is: Should the exception thrown by the parsing library be treated the same as MyException given that both are business rules?

4

Depending on the way those errors are presented to the user of the API, it may be OK, or may not.

For both errors, it is important to have:

  • The indication that something went wrong. With REST, this means sending an HTTP 403 or a similar status code in the response. It also usually translates into a JSON which is visually identifiable as being an error (for instance by naming the root JSON node error).

  • The concerned field, that is name.

  • The description of the error, i.e. what went wrong. Is the name field missing? Or it was found, but the value is invalid? In other words, the user should be able to identify the mistake in the input.

The type of the underlying exception is not necessary. It could be MyApp.Something.Whatever.BusinessRules.InvalidUserNameException or JsonSerializer.Validation.NullFieldException. The user of the API doesn't care, and shouldn't see the types anyway, since this reflects the implementation, and would vary if you refactor your code, or if you move to another language or serialization library.

So:

  • Having exceptions from the JSON library side by side with your own, custom exceptions, is perfectly normal.

  • But this should still result in uniform messages shown to the end user.


A side note about the actual business rule:

A Person's name mustn't consist solely of spaces and/or tabs

Why not? Why would a non-breaking whitespace (U+00A0) be a valid name, but a tab wouldn't?

If your intention is to prevent users from screwing up with your system, you'll fail anyway. With Unicode, there are a lot of ways to do funny stuff which will display very... nicely (or which won't display at all). Or you may restrict your users to [A-Za-z ] range, which would be technically very convenient, and would also make it impossible to enter the names of most of the persons in the world.

Otherwise, I can't see a case where the user would enter a tab as a name by mistake, and if this is a frequent case, you may check twice the user interface which encourages this sort of errors.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.