Among the Available index types I could see only one kind of index that would be able to cause an error on an object that depends on the table and it's the Unique index.
According to the Unique Index Design Guidelines:
A unique index guarantees that the index key contains no duplicate
values and therefore every row in the table is in some way unique.
It's an index that comes with a constraint that ensures the values are unique. Apart from that very specific situation, you don't have to worry about breaking a dependency for, as the doc says,
A nonclustered index is an index structure separate from the data
stored in a table that reorders one or more selected columns. (emphasis mine)
As you can see, the nonclustered index is separeted from the table and doesn't alter the structure of the table itself, therefore, anything that uses that table shall not be negatively affected the way you're afraid of.
Here's a good start point: SQL Server Index Architecture and Design Guide
Lab: causing error on table dependency by creating an index
First, create a table that will have an object that depends on it:
CREATE TABLE MyTable(
UserID INT NOT NULL IDENTITY PRIMARY KEY,
Name VARCHAR(50) NOT NULL,
Surname VARCHAR(50) NOT NULL
Now, crete an SP that is dependent on that table:
CREATE PROCEDURE InsertUser
INSERT INTO MyTable(Name, Surname)
Let's insert the user Paul Smith:
EXEC InsertUser 'Paul', 'Smith';
The procedure executes fine. Paul is a very common name and as it is now you could insert as many users named Paul as you wished. But you decided to create a Unique Index on the column Name:
CREATE UNIQUE INDEX AK_MyTable_Name ON MyTable (Name);
After that, you try to insert another user named Paul Jones:
EXEC InsertUser 'Paul', 'Jones';
But now you get an error:
Msg 2601, Level 14, State 1, Procedure InsertUser, Line 6 [Batch Start
Line 17] Cannot insert duplicate key row in object 'dbo.MyTable' with
unique index 'AK_MyTable_Name'. The duplicate key value is (Paul). The
statement has been terminated.
The SP that depended on the table is now broken. That's the only situation I can imagine you could break an object that depends on a table by the creation of an index. If you're not creating a Unique Index now, you can relax and watch the performance of your new indexes.