WSC 3.0 — Error Handling

  • In previous versions of WoltLab Suite Core / Community Framework almost all the exceptions thrown were SystemExceptions. The reason for this was that only a SystemException and it’s subclasses could be properly logged. This made it hard for developers to distinguish between expected errors (i.e. runtime errors) and programming mistakes. WoltLab Suite Core 3.0 lifts the first restriction, allowing any exception to be properly logged and uses different subclasses of \Exception to distinguish between different types of errors.

    What does this mean for me?

    Basically two things:

    • catch (SystemException $e) might not catch all the exceptions any more.
    • You should take the proper action depending on the type of the Exception thrown.

    As an example: WoltLab Suite Core 3.0 makes heavy use of the predefined SPL exceptions inside of new code:

    A LogicException is defined to: “lead directly to a fix in your code”. This means that you should not catch this type of Exception inside your code and instead should let the request crash, as your code is erroneous and violates some condition the API expected. This kind of mistake should not be silently ignored.

    On the other hand a RuntimeException can and will happen randomly, you absolutely should catch a RuntimeException (or a subclass of it) and take proper action based on the exact type of the Exception. When a fictitiousNetworkOutageException is caught you might retry the very same request for a second time, whereas an HTTPNotFoundException might lead to the removal of a stored resource.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!