IceLib methods throw a variety of exceptions that should be handled appropriately in order to avoid having unhandled exceptions (and subsequent application crashes) in an IceLib-based application. These exceptions are generally documented on each IceLib method that can throw them. There are some general practices that should be followed to ensure that an IceLib-based application is resilient to these exceptions.
A common set of exceptions that IceLib can throw are related to input parameters being passed in to methods and class constructors such as , , and . IceLib methods that require communication with the IC Server have a number of additional exceptions that can be thrown such as RequestTimeoutException, SessionDisconnectedException, and .
Aside from handling specific exceptions that an IceLib-based application may want to handle, it is generally a good idea to also include an IceLibException and/or catch block. This is to ensure that the IceLib-based application can handle other exceptions being thrown, such as the InsufficientRightsException that can be thrown when making calls that communicate with the IC Server. This will help to ensure that the IceLib-based application is resilient to exceptions that were unexpected at the time the application was written.
The following block of code shows an IceLib method call that is resilient to various exceptions that can be thrown:
_Session.ChangeStation(new ININ.IceLib.Connection.WorkstationSettings(workstation, supportedMedia));
// Somehow the workstation parameter was null,
// notify the user...maybe there was a bad
// input check?
catch (ININ.IceLib.Connection.SessionDisconnectedException ex)
// The connection was disconnected. Do
// something specific about this exception,
// like kicking the user back to a login
// screen after notifying them.
catch (ININ.IceLib.IceLibException ex)
// Some other IceLib exception happened that
// we weren't expecting. Notify the user in
// some way, and perhaps log it for future
catch (Exception ex)
// Some other exception happened. Write it
// to a log, or do something else so that it
// can be further investigated.