In SharePoint 2010 you can add your own custom error page instead of using the OOTB error page. Just add a new application page to your event receiver project use the code below where you want to show the error…
//The event is cancelled, but a URL is provided that redirects to a custom error message page, or to any URL.
properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;
properties.RedirectUrl = “/_layouts/myCustomErrorPage.aspx”;
At some point while working with event handlers you’ll have some config settings that will need to be stored, and we all know it’s not acceptable to hard code them. I like store them in the web.config, but this blog that breaks downs the all the options for you.
http://www.sharepoint-tips.com/2008/04/event-handlers-configuration-settings.html
I think the blog below does a great job breaking down the decision criteria to pick the right solution for your requirement. You can see the original blog here.
A SharePoint event handler or event receiver is a piece of code that runs when an event, such as the adding, deleting, or changing of a SharePoint list item or document, takes place.
They react to changes just like a SharePoint workflow can react to those same changes made to an item.
The main differences between SharePoint event handlers and SharePoint workflows are:
Initiation
SharePoint event handlers are automatically initiated, while SharePoint workflows can be initiated either automatically or manually.
Response
A SharePoint event handler always responds to an event that has taken or is taking place on an item, while a SharePoint workflow does not necessarily have to react to an event that is taking place. While it can react to an item being created or changed, you can also manually start a workflow after an item has been created.
User Interaction
SharePoint event handlers have no user interface, so users cannot interact with event handlers. On the other hand, you can create either ASP.NET or InfoPath forms to provide user interactivity with SharePoint workflows. And you can add even more interactivity by using SharePoint Tasks lists along with the workflow.
Duration
SharePoint event handlers run for a short period of time (generally seconds), while SharePoint workflows may run for a much longer time period (days, months, or even years).
Robustness
Since SharePoint workflows are hydrated and dehydrated, they can “survive” server reboots, while SharePoint event handlers cannot.
When deciding whether to go with a SharePoint event handler or a SharePoint workflow for a piece of functionality or business logic that you require, consider the 5 points mentioned above.
Go with a SharePoint event handler if the tasks you want to perform are directly related to the user taking a particular action on an item (such as adding, editing, or deleting it), you do not require the user to interact with your code, and whatever the event handler has to do is of a short duration.
Go with a SharePoint workflow if the tasks you want to perform are not directly related to the user taking a particular action on an item, you require interaction between the user and your code, your code may run for a long duration, and should live through server reboots.
