Return details of error without Exceptions

Question

I Just ask this: Is it bad to use exceptions to end function?.

Now I understand we should not return exceptions. So, what is the right way to return errors?

When I return an exception, when something fails, I know what was the error inside the function.

But if instead a void function with multiple exceptions, I have a boolean function returing true if it was OK, and false if something fails, how can I know the exact thing that fails?

A function can fails for multiple reasons, so returing just a False is not ok for my program. When I return an Exception with some text I can show to the user the exact error.

Having an string function an returning a word like "Correct" or the different errors doesn't look like the best thing for me. What is the recommended approach?

read comments from your previous post.. and follow some advice `Don't use exceptions to control program flow.` — MethodMan, Jan 27 '14 at 01:05
@DJKRAZE I understood that in my prior qestion and I am not asking the same thing. Now I am doing a Question about how should I address another (related) issue. And I am doing it in a new question like André Snede Hanse suggested in the other question. — Ricardo Polo Jaramillo, Jan 27 '14 at 01:07
You can return an enum instead of a bool. If you need more info then you can return a class object instead of an enum. Such a class is likely to start resembling an Exception object. So no, it isn't actually wrong to return an Exception. What's wrong is opening the opportunity for the caller to ignore it, that never ends well. You *never* worry that exception handling is slow, it doesn't matter that it takes 50 microseconds for a program to not do what it is supposed to do. — Hans Passant, Jan 27 '14 at 01:53
@HansPassant how do you manage the error class, do you return it from the functions? But if you expect your function to return another class and not the error class? — Ricardo Polo Jaramillo, Jan 27 '14 at 12:34

Grant Winney · Answer 1 · 2014-01-27T03:12:14.390

"...how can I know the exact thing that fails?"

Asking that question might mean you've got too much going on in the method and it's time to refactor.

Here's your example, copied from your previous question:

void Function1()
{
    //Do something...
    //If something fail
    Throw New Exception("Fails because bla bla");

    //Do something...
    //If something fail
    Throw New Exception("Fails because bla bla bla bla");

    //If everything its ok, just continue without throwing anything
}

Function1 is doing a lot. To make maintenance (and testing) easier, you could extract groups of logic into separate methods, each of which returns a bool value to indicate success.

bool SomethingOne()
{
    var successful = true;

    //Do something...
    //If something fail
        successful = false;

    return successful;
}

bool SomethingTwo()
{
    var successful = true;

    //Do something...
    //If something fail
        successful = false;

    return successful;
}

void Function1()
{
    var isOneSuccessful = SomethingOne();
    if (!isOneSuccessful)
    {
        // SomethingOne failed - do something
        return;
    }

    var isTwoSuccessful = SomethingTwo();
    if (!isTwoSuccessful)
    {
        // SomethingTwo failed - do something
        return;
    }

    //If everything its ok, just continue without throwing anything
}

YMMV. I'm assuming that "something fails" is a non-critical problem. Like maybe this is a validation routine and you're just going to display a message that says "Please check all fields."

If it's something the programmer using your method needs to be aware of and handle specially, or if it's something the user has to know more about, a simple boolean may not cut it.

score 1 · Answer 2 · answered Jan 27 '14 at 01:15

The recommended approach is going to vary widely, depending on who you ask.

The way that we have implemented this in a a very large system is to include a structured error class as one of the parameters to the method or as the return from the method, depending on needs.

This error class contains an error code so that we can perform translations of well-known errors, a message string to hold the user-consumable message, and various flags that can be used to indicate retryability, fatality, etc.

We use this error class throughout all levels of our application, from our application server through to mobile devices and web service methods.

This is just our approach and has worked well for us, but your implementation may require a different approach.

Return details of error without Exceptions

2 Answers2

Linked