Question: Most of the programming languages do not have checked exceptions (like C# and Kotlin).

So, I'm trying to find a better approach for a case that I have in my project without using checked exceptions.

The project uses Java and we control the possible validation errors from a Remote EJB. Something like this:

```
lookupSomeRemoteEjb().createCustomer(/** lots of informations */);

```

This method throws many exceptions of validation, like:

```
DocumentoAlreadyExistsException();
InvalidNameException();
InvalidBirthDateException();

```

And etc.

This exceptions can happen in different classes in different levels. Like this example:

```
CustomerRemoteEjb.class // tell to the another system what error happened
    CustomerService.class //can throw some errors about customer
        PersonService.class // can throw some errors about person
            DocumentService.class // can throw some errors about document
            AddressService.class // can throw some errors about address

```

An API calls this remote EJB and catch every single error, translating this for a nice message to the API user (that uses this remote EJB).

Works well, but the code is a messy with a lot of ugly try/catch for each call.

I suppose that the alternative is use unchecked exceptions with an ID error or using something like a `Result` object with the same kind of ID for the validation error.

But this solutions don't fit very well in a more complex code (a monolyth system, by the way), because many times these validations are made from a service called by another service. It will be strange this deep services return exception (or result objects) with an ID to another services before they reach the API. 

I read some [old discussion about](http://wiki.c2.com/?CodeWithoutExceptions) the alternative for checked exceptions, but there are no conclusion about the best alternative. I still agree with a comment there:

> 
> I'm reading the above discussion and I'm still left not knowing if exceptions are any good.
> 
> 
> 

So, in a similar situation, how can I resolve this problem with languages that do not support checked exceptions?

Answer: 
For checked exceptions, you could use only one generic **SystemException**. And this it would solve the 'catching multiple exceptions' problem.

However **SystemException** need to have information about your exceptions like errorCodes and/or messages for the integrations (like Remote EJB) use them.

For Legacy Code, I would suggest:

* Turn all the **LegacySpecificException** extending
**SystemException** (or)
* Turn all the **LegacySpecificException** into **SystemException**

Another problem: If you need to "try-catch" another exception rather than **SystemException**(**EJBException** for example), you'll need to treat that and rethrow a **SystemException**.

```
} catch (EJBException e) {
  throw new SystemException(e.getMessage(), e);
}

```

\*ref: <https://northconcepts.com/blog/2013/01/18/6-tips-to-improve-your-exception-handling/>
For the types of exceptions you list:

* DocumentoAlreadyExistsException();
* InvalidNameException();
* InvalidBirthDateException();

You could write a validation method that validates the input and returns a validation data value object. This validation method and data value object will evolve as the application evolves and the complexity of the validation is encapsulated in this method and will probably exist in its own class (and may call on other classes to do other specific tasks). 

You could then do one of a number of options. 

You could create a single Exception class ValidationException that has the validation data value object as an instance variable. At the beginning of your original method call the validation method, create and throw an instance of the validation exception class with the validation data value object as an instance variable. 

You could call the validation method prior to the call to the original method and not call the original method if validation fails. 

Both.