I have views that handle different errors in my application. For example error 404, 403 and such, giving my errors a more user-friendly presentation. By assumption, they get passed in an exception, so this is what an example error-handling view looks like:
<h1>Whooops! An error with code <?=$exception->getCode()?> has occurred.</h1>
<p><?=$exception->getMessage()?></p>
But somewhere along the lines I met a need to display a certain error view as only a part of a page, so I decided why not do this
// somewhere in another view
echo $errorView->render(new Exception('Message', 403));
My question is whether in my particular case it is a good programming practice to be throwing exceptions? Or should I handle it differently than how I am handling it now?
9
You’ve got a situation where an exception occurs for some reason or another. There’s really no point going on and you need to start bailing out and rendering the corresponding web error page (this is a web application after all).
Now, to present some information to the end user, you need to somehow get some data to that error page. And to that extent, an exception is a good place to put that data.
Other options are convoluted where one tries to stuff the data in a session context or somewhere that is ‘anywhere but the exception’. But why not the exception? It can hold data (be it a message or the type of the exception or any other data that it is wrapping in other situations) and it is present when you are rendering the final response.
Using the exception to hold this data is the perfect place to put such information. It keeps it together, it makes it available to the parts of the application that need it and it clearly shows its intent and responsibility.
Should error pages only take exceptions? That is a bit of a trickier question. And that, it feels a bit awkward in that you are creating an exception object, but not throwing it and instead passing it as an argument. And that has some ‘icky’ feeling to it, but could be necessary for other parts of the application that aren’t presented here.
Other parts of the application may behave specially when exceptions start floating around (like loggers or other cross cutting aspects taking action when an exception is created). But, again, without further information about the architecture this is pure speculation.
I would be tempted to make an interface of an Error (note that this is kind of hand wavy here and may not be applicable to all language paradigms). Then have a specific exception type implement this interface… along with a non-exception object implementing it too. Then have the Error object be sent to the rendering page. This would allow one to create an ErrorException when needed, but also just creating an Error when you don’t need an exception.
2