I don't seem to be able to grasp this properly.

By using exceptions and try catch blocks you can nicely grab all your errors and do anything that you want.

But why?

Errors aren't supposed to be happening in the first place, so why would you code your way around it? There's no point in covering them up using catch blocks right?

Instead I think a coder should make sure that the error cannot and does not happen, to maintain application integrity.

I can't grasp the advantage, even though I really want to. But how does an exception handler give you a better way to handle issues then just debugging your code properly?

Using die() or trigger_error() generally gives enough flexibility to show what shouldn't have been happening, so it can't be fixed. Why code an exception handler around that?

Note that I'm not trying to flame exception lovers or anything 😉 but I think I'm missing an important area here -- the area that shows the actual advantage, which makes me use exceptions. 🙂

Well any input is appreciated 🙂

Thanks

    Desdinova wrote:

    By using exceptions and try catch blocks you can nicely grab all your errors and do anything that you want.

    But why?

    Errors aren't supposed to be happening in the first place, so why would you code your way around it? There's no point in covering them up using catch blocks right?

    Instead I think a coder should make sure that the error cannot and does not happen, to maintain application integrity.

    I can't grasp the advantage, even though I really want to. But how does an exception handler give you a better way to handle issues then just debugging your code properly?

    Some exceptions are used to indicate pre-condition violations (and other logic errors) in functions that form the interface of a library. In such cases, yes, the exceptions denote programming errors that can be avoided. However, they are thrown nonetheless as a safety net: the code that uses the library cannot do much more than catch the exception, log it, and display some message to the user informing him/her that the script has failed. However, the programmer can then view the log and fix the problem. This is better than the script failing even more mysteriously and possibly disastrously at some later point because of the pre-condition violation.

    Other exceptions are used to indicate runtime problems that cannot be easily avoided. For example, maybe a configuration file could not be opened, or maybe it can be read, but the configuration is in a wrong format. One could call specially designed functions to check for these kind of errors, but it tends to be easier to just attempt the operation, then catch the exception appropriately. The client code might still catch and log the exception and display an error message, but it also might do something else, e.g., use a default configuration.

    Desdinova wrote:

    Using die() or trigger_error() generally gives enough flexibility to show what shouldn't have been happening, so it can't be fixed. Why code an exception handler around that?

    die and trigger_error() are not very graceful ways of terminating a script. They are good for testing, but not so good for production.

      Thanks.

      So basically, if a coder built an application that is or should be error free, there would still be exceptions in place for very extremely weird unexpected errors, which'll allow the script to degrade gracefully, even though the entire backend might be blown away (lets say disk corruption). All the user would then see is the catch: 'Oops, it's not working'. While the log would show more expressed notes like 'Where the crap did all files go?'.

      And next to that, exceptions can be used not really for error handling, but just to give it a good shot, and if it's not working then oh well. I can see this as a benefit when users upload a custom config file for instance. That could make sense. Does have a dirty edge to it if you ask me though.

      What do you think about my 'summary' on it?

        Desdinova wrote:

        So basically, if a coder built an application that is or should be error free, there would still be exceptions in place for very extremely weird unexpected errors, which'll allow the script to degrade gracefully, even though the entire backend might be blown away (lets say disk corruption).

        Yes. Of course, this is assuming that exceptions are used instead of error codes. Exceptions have an advantage over error codes in that they cannot be completely ignored, and yet they can be easily handled or translated at the appropriate level (e.g., a function foo may call another function that might throw an exception, but foo itself is unable to properly handle that exception if it is thrown). However, they have a disadvantage in that it can be difficult to tell if a function call can result in an exception, and thus code might be written in a way that is not exception safe (though with automatic resource management, e.g., garbage collection, this is less of a problem).

        Desdinova wrote:

        And next to that, exceptions can be used not really for error handling, but just to give it a good shot, and if it's not working then oh well. I can see this as a benefit when users upload a custom config file for instance. That could make sense. Does have a dirty edge to it if you ask me though.

        That is a form of error handling, or maybe exceptional situation handling, e.g., it is usually the case that the custom configuration file would be in the right format if it exists.

          Thanks. I guess setting the error handler to throw an exception gives some extra options with this.

          Can you touch on this a little deeper:

          laserlight;10934705 wrote:

          However, they have a disadvantage in that it can be difficult to tell if a function call can result in an exception, and thus code might be written in a way that is not exception safe (though with automatic resource management, e.g., garbage collection, this is less of a problem).

          Are you talking about writing a catch for something that never returns an exception and that being a disadvantage?

            Desdinova wrote:

            Are you talking about writing a catch for something that never returns an exception and that being a disadvantage?

            No, that would be pointless but otherwise not harmful. I am talking about something else. For example, suppose that you opened a file and took a lock on it. Then before you can release that lock, you call a function and an exception is thrown. If the lock was not released automatically, then you would have a situation where the code to release the lock is never reached because the thrown exception has transferred control elsewhere, so the file remains locked (at least for longer than it should be).

              Ok. thanks for your thoughts, I appreciate it.

                Write a Reply...