Why not to use Array of errors instead of Exception Handling !?

Question

Why not using array of errors instead of throwing errors and check if it's not empty later in the code.... Exception handling is very confusing to me , I can not understand it's purpose ... can anybody enlighten me !?

they compare it with die() as better not to stop the execution of the code , why would I stop the execution of code if I don't want to !? ofcourse I do

I'm a beginner programmer , it might be confusing to you as well , or because i'm not very experienced in this ugly thing.

Please in the context of PHP only.

Answer 1

It really depends what type of error you're talking about.

I always die(); for really bad errors, like if the application couldn't connect to the database.

But for anything that takes user input, like a form, it's better to use arrays of errors that the user can see all at once, instead of correcting one field at a time and repeatedly having to press submit.

(If you want to know in more detail, I often use an array of arrays to display errors, since one field could potentially have multiple things wrong with it. For example, if a user tries to register an account with username "1337", I will use a validator to check against multiple conditions and it will return an array with things like "username must be at least 5 characters long", "username must contain at least three letters", "that username has been disallowed by the administrator" and all those messages will be displayed simultaneously above that particular field)

Answer 2

One reason you might decide to throw an exception is because you can add a jump in control flow without an explicit piece of syntax. What do I mean by that?

rather than

$returnVal = doSomeDiskFunction();
if($returnVal == $ERROR_CODEA)
{
    // do some stuff
}
else if( $returnVal == $ERROR_CODEB)
{
    //do some stuff
}

$returnVal = doSomeOtherDiskFunction();
if($returnVal == $ERROR_CODEA)
{
    // do some stuff
}
else if( $returnVal == $ERROR_CODEB)
{
    //do some stuff
}

you could just have

try{
   doSomeDiskFunction();
   doSomeOtherDiskFunction();
}
catch(ExceptionTyepA $exceptionA)
{
    //do some stuff
}
catch(ExceptionTypeB $exceptionB)
{
    //do some stuff
}

Seems a lot cleaner, yes??? It's also a formal way of alerting calling code that it needs to deal with potential error conditions if you choose to have the exception propogate upwards in the call stack.

Also, exceptions should be used for code that you don't expect to happen, like failing to connect to a database, not code that you DO expect to happen, like a user submitting bad data. The other poster made the point that you kind of expect a user to make a lot of errors filling out a form, so you wouldn't throw an exception when you come across some data that is in a bad user-entered format, because you expect user data to be poor quality.

Answer 3

There is a way to code completely without exception handling. For example, if you have a method that returns the length of an object, have it return -1 if there's been an error. This is how most C API's are built.

That said, when you're building complex systems, and you have a ton of "black box" code that might behave wrongly, exceptions help. The way exceptions work is like this: when someone "throws", folks on the call stack start getting notified. One step at a time. One of these methods can "Catch" the exception and handle it.

Why is this useful: you can have a DB layer that has lots of logic inside that throws exceptions. If something goes wrong there, your DB exception handling code can fail gracefully, showing a nice error message to the user; it can also send a text message to the admin, demanding attention.

You can even create a hierarchy of exception handlers: you can re-throw the exception after you've done something with it.

Answer 4

PHP's exceptions sucks hard, but they still have their basics benefits:

1. Exception provides much more information about "What went wrong?" in much better form (exception is an object)
2. They make your code clearer
3. They are the only reasonable way to break execution of the part of code (that doesn't work as it supposes to), fix (if possible) what need to be fixed and continue without complete failure.

Answer 5

Really it depends on the language. C is similar in that respect -- it doesn't force you to handle an error. Most functions return -1 if they had a problem; it's up to you to check 'errno' to see what happened.

Exceptions are generally a good thing though. You rarely want to blindly continue running if an error occurred (Never never NEVER say "On Error Resume Next" in Visual Basic. Please.). It's quite easy to catch the exception and do nothing if you are sure you don't need to do anything.