Class Exceptions
Exceptions class provides operation to log most of the exceptions occurred in system.
Inheritance
Namespace: DotNetNuke.Services.Exceptions
Assembly: DotNetNuke.dll
Syntax
public sealed class Exceptions : object
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
Methods
| Improve this Doc View SourceGetExceptionInfo(Exception)
Gets the exception info.
Declaration
public static ExceptionInfo GetExceptionInfo(Exception e)
Parameters
Type | Name | Description |
---|---|---|
Exception | e | The exception. |
Returns
Type | Description |
---|---|
ExceptionInfo | Exception info. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
LogException(ModuleLoadException)
Logs a ModuleLoadException.
Declaration
public static void LogException(ModuleLoadException exc)
Parameters
Type | Name | Description |
---|---|---|
ModuleLoadException | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
LogException(PageLoadException)
Logs a PageLoadException.
Declaration
public static void LogException(PageLoadException exc)
Parameters
Type | Name | Description |
---|---|---|
PageLoadException | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
LogException(SchedulerException)
Logs a SchedulerException.
Declaration
public static void LogException(SchedulerException exc)
Parameters
Type | Name | Description |
---|---|---|
SchedulerException | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
LogException(SecurityException)
Logs a SecurityException.
Declaration
public static void LogException(SecurityException exc)
Parameters
Type | Name | Description |
---|---|---|
SecurityException | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
LogException(Exception)
Logs an exception.
Declaration
public static void LogException(Exception exc)
Parameters
Type | Name | Description |
---|---|---|
Exception | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
LogSearchException(SearchException)
Logs the search exception.
Declaration
public static void LogSearchException(SearchException exc)
Parameters
Type | Name | Description |
---|---|---|
SearchException | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessHttpException()
Exceptions class provides operation to log most of the exceptions occurred in system.
Declaration
public static void ProcessHttpException()
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessHttpException(HttpException)
Exceptions class provides operation to log most of the exceptions occurred in system.
Declaration
public static void ProcessHttpException(HttpException exc)
Parameters
Type | Name | Description |
---|---|---|
HttpException | exc |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessHttpException(HttpRequest)
Exceptions class provides operation to log most of the exceptions occurred in system.
Declaration
public static void ProcessHttpException(HttpRequest request)
Parameters
Type | Name | Description |
---|---|---|
HttpRequest | request |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessHttpException(String)
Exceptions class provides operation to log most of the exceptions occurred in system.
Declaration
public static void ProcessHttpException(string url)
Parameters
Type | Name | Description |
---|---|---|
System.String | url |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessModuleLoadException(Control, Exception, Boolean)
Processes the module load exception.
Declaration
public static void ProcessModuleLoadException(Control ctrl, Exception exc, bool displayErrorMessage)
Parameters
Type | Name | Description |
---|---|---|
Control | ctrl | The control. |
Exception | exc | The exception. |
System.Boolean | displayErrorMessage | if set to |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessModuleLoadException(Control, Exception)
Processes the module load exception.
Declaration
public static void ProcessModuleLoadException(Control ctrl, Exception exc)
Parameters
Type | Name | Description |
---|---|---|
Control | ctrl | The control. |
Exception | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessModuleLoadException(PortalModuleBase, Exception, Boolean)
Processes the module load exception.
Declaration
public static void ProcessModuleLoadException(PortalModuleBase objPortalModuleBase, Exception exc, bool displayErrorMessage)
Parameters
Type | Name | Description |
---|---|---|
PortalModuleBase | objPortalModuleBase | The control. |
Exception | exc | The exception. |
System.Boolean | displayErrorMessage | if set to |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessModuleLoadException(PortalModuleBase, Exception)
Processes the module load exception.
Declaration
public static void ProcessModuleLoadException(PortalModuleBase objPortalModuleBase, Exception exc)
Parameters
Type | Name | Description |
---|---|---|
PortalModuleBase | objPortalModuleBase | The control. |
Exception | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessModuleLoadException(String, Control, Exception, Boolean)
Processes the module load exception.
Declaration
public static void ProcessModuleLoadException(string friendlyMessage, Control ctrl, Exception exc, bool displayErrorMessage)
Parameters
Type | Name | Description |
---|---|---|
System.String | friendlyMessage | The friendly message. |
Control | ctrl | The control. |
Exception | exc | The exception. |
System.Boolean | displayErrorMessage | if set to |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessModuleLoadException(String, Control, Exception)
Processes the module load exception.
Declaration
public static void ProcessModuleLoadException(string friendlyMessage, Control ctrl, Exception exc)
Parameters
Type | Name | Description |
---|---|---|
System.String | friendlyMessage | The friendly message. |
Control | ctrl | The control. |
Exception | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessModuleLoadException(String, PortalModuleBase, Exception, Boolean)
Processes the module load exception.
Declaration
public static void ProcessModuleLoadException(string friendlyMessage, PortalModuleBase objPortalModuleBase, Exception exc, bool displayErrorMessage)
Parameters
Type | Name | Description |
---|---|---|
System.String | friendlyMessage | The friendly message. |
PortalModuleBase | objPortalModuleBase | The control. |
Exception | exc | The exception. |
System.Boolean | displayErrorMessage | if set to |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessPageLoadException(Exception, String)
Processes the page load exception.
Declaration
public static void ProcessPageLoadException(Exception exc, string url)
Parameters
Type | Name | Description |
---|---|---|
Exception | exc | The exception. |
System.String | url | The URL. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessPageLoadException(Exception)
Processes the page load exception.
Declaration
public static void ProcessPageLoadException(Exception exc)
Parameters
Type | Name | Description |
---|---|---|
Exception | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels:
ProcessSchedulerException(Exception)
Processes the scheduler exception.
Declaration
public static void ProcessSchedulerException(Exception exc)
Parameters
Type | Name | Description |
---|---|---|
Exception | exc | The exception. |
Remarks
Logging is an import part of a good architecture. A good practice is to provide enough logging to accurately be able to identify which code caused an exception. Some exceptions are expected and you can display information to the user to help him figure out what happened. It is however bad practice to catch any and all exceptions (general exception) and display this to users. In such situations it is best to provide the user with a general message and only log the details in a way that the details are either just visible to administrators (Event Log) or only to SuperUsers (hosts) in the server logs.
Currently we implement a lot of custom exception to use in different levels: