So this is a follow-up to a previous question that I asked: Trying to figure out if this code creates any benefit by using a Singleton
In a nutshell, I have inherited a poorly architected program that uses a pseudo-facade class and places it into a Singelton. Every method call goes through the Singleton which then calls different methods.
The Singelton looks like this:
public class FooFacade
{
private static FooFacade m_facade = null;
private static DataAccessManager m_dataAccessMgr = null;
public StringBuilder Status {get; set; }
private FooFacade()
{
this.Status = new StringBuilder();
}
public static FooFacade getInstance()
{
if (m_facade == null)
{
m_dataAccessMgr = DataAccessManager.getInstance();
m_facade = new FooFacade();
}
return m_facade;
}
public void clearStatus()
{
this.Status.Remove(0, Status.Length);
}
public void Method1(string value1, int value2)
{
// do something
}
public int Method2(int value1, int value2)
{
return externalMethod(value1, value2)
}
}
So in this example above, would there be a security concern if the externalMethod that is being called in Method2 threw an error?
For example:
public int externalMethod(value1, value2)
{
try
{
return value1/value2;
}
catch
{
throw;
}
}
In this method, should I be concerned that a Singleton could display a thrown error to the wrong user?
When I have the chance to refactor, I'm getting rid of the Singleton, but in the meantime, I just don't want to accidentally add a huge security hole by adding better exception handling.
-Chad