TECHNICAL FIELD

Embodiments herein concern methods and arrangements, e.g. an error

management server, for managing a program error of a computer program executed by a device, e.g. by a personal computer, smart phone or the like.

BACKGROUND

When a software program error occurs that affects a user of the program, the user typically must perform an investigation to find out why the error occurred and how to be able to solve the task that the user was trying to do in the program despite the error. This process may involve searching the web or contacting the support of the program providing company, e.g. the company developing the program. It is time consuming and increases the support costs for the company. Hence, program errors, in addition to what the error as such directly causes, takes time and resources both from the user that experiences the error but also from the company providing the program.

US 6918059 B1 discloses a method for processing an error occurring in a system element operating in a computer system. When a connection exists between the system element and the central-resource, an error message is transmitted from the system element to the central resource. An assistance option is selected from a plurality of assistance options in accordance with the error message and the error message is filtered for an error type. The assistance option is then provided to the system element through a routine server in accordance with the error type.

Centralizing error management like this enable improved assistance on

encountered errors compared to more conventional error management.

SUMMARY

In view of the above, an object is to provide one or more improvements in relation to the prior art and relating to management of program errors of computer programs when executed by a device and encountered by users of the computer program. A more particular object may be reduce the workload that users of computer programs are subject to when encountering program errors.

According to a first aspect of embodiments herein, the object is achieved by a method, performed by a device, for managing a program error of a computer program executed by the device. The device detects, during and from execution of the computer program on the device, occurrence of the program error. The device forms an error report for identification of the program error based on error identifying information relating to at least an error type associated with the detected program error and a stack trace associated with the program error. The device then sends the error report, via a computer network, to an error management server configured to receive error reports from one or more devices executing the computer program.

According to a second aspect of embodiments herein, the object is achieved by a computer program comprising instructions that when executed by a processing circuit causes the device to perform the method according to the first aspect.

According to a third aspect of embodiments herein, the object is achieved by a carrier comprising the computer program according to the second aspect.

According to a fourth aspect of embodiments herein, the object is achieved by a method, performed by an error management server, for managing a program error of a computer program executed by a device. The error management server being configured to receive error reports for identification of program errors from one or more devices executing the computer program. The error management server receives, from the device via a computer network, an error report for identification of the program error based on error identifying information relating to at least an error type associated with the program error and a stack trace associated with the program error. The error management server obtains, based on the received error report, an error identifier identifying the program error, the error identifier identifying the program error among other program errors that may occur. The error management server initiates comparison of the obtained error identifier with previously generated identifiers identifying program errors occurred in execution of the computer program on devices and that have been previously reported by means of other error reports. Said previously generated identifiers being associated with error managing information relating to error status regarding a solution to and/or recommended user actions for managing the program errors identified by the previously generated identifiers, respectively. The error management server generates a response message based on the comparison and comprising the error managing information, if any, associated with the program error identified by the error identifier. The error management server sends the generated response message to the device via the computer network.

According to a fifth aspect of embodiments herein, the object is achieved by a computer program comprising instructions that when executed by a processing circuit causes the error management server to perform the method according to the fourth aspect.

According to a sixth aspect of embodiments herein, the object is achieved by a carrier comprising the computer program according to the fifth aspect

According to a seventh aspect of embodiments herein, the object is achieved by a device for managing a program error of a computer program executed by the device. The device is configured to detect, during and from execution of the computer program on the device, occurrence of the program error. The device is further configured to form an error report for identification of the program error based on error identifying information relating to at least an error type associated with the detected program error and a stack trace associated with the program error. The device is configured to send the error report, via a computer network, to an error management server configured to receive error reports from one or more devices executing the computer program.

According to an eighth aspect of embodiments herein, the object is achieved by an error management server for managing a program error of a computer program executed by a device, which error management server is configured to receive error reports for identification of program errors from one or more devices executing the computer program. The error management server is further configured to receive, from the device via a computer network, an error report for identification of said program error based on error identifying information relating to at least an error type associated with the program error and a stack trace associated with the program error. The error management server is configured to obtain, based on the received error report, an error identifier identifying the program error, the error identifier identifying the program error among other program errors that may occur. Moreover, the error management server is configured to initiate comparison of the obtained error identifier with previously generated identifiers identifying program errors occurred in execution of the computer program on devices and that have been previously reported by means of other error reports. Said previously generated identifiers being associated with error managing information relating to error status regarding a solution to and/or recommended user actions for managing the program errors identified by the previously generated identifiers, respectively. Further, the error management server is configured to generate a response message based on the comparison and comprising the error managing information, if any, associated with the program error identified by the error identifier. The error management server is configured to send the generated response message to the device via the computer network.

Thanks to the error report for identification of the program error based on error identifying information relating to the stack trace in addition to the error type, it is enabled to generate an identifier identifying the program error with an improved ability to distinguish different errors from each other compared to if only error type is used. The identifier may be generated based on the error identifying information so that the same identifier can, or will, be generated for the same program error even if it occurs at different occasions and/or on different devices.

The error management server may obtain such error reports and identifiers from multiple devices experiencing program errors, and for each obtained error identifier compare to previously stored error identifiers and find associated error managing information, such as relating to error status and recommended user actions, e.g. what a user should know about the program error, if it has or will be fixed, when, in which version, and/or what the user can do to avoid it or reduce effect from the error etc.

Hence, thanks to embodiments herein, is possible to reduce the workload that users of the computer program conventionally are subject to when encountering program errors, as described in the Background. In other words, embodiments herein provide

improvements relating to management of program errors of computer programs when executed by a device and encountered by users of the computer program.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to the appended schematic drawings, which are briefly described in the following.

Figure 1 is a block diagram schematically depicting an example of devices and an error management server connected via a computer network. Figure 2 is a combined signaling diagram and flowchart for describing embodiments herein.

Figures 3a-c schematically exemplify error information that may be presented to a user based on embodiments herein.

Figure 4 is a functional block diagram for illustrating embodiments of a device according to embodiments herein and how it can be configured to carry out related actions of a method.

Figure 5 is a functional block diagram for illustrating embodiments of an error management server according to embodiments herein and how it can be configured to carry out related actions of a method.

Figure 6 is a schematic drawing illustrating embodiments relating to a computer program, and carrier thereof, to cause the device and error management server to perform respective methods with related actions.

DETAILED DESCRIPTION

Throughout the following description similar reference numerals may be used to denote similar elements, units, modules, circuits, nodes, parts, items or features, when applicable. Features that appear only in some embodiments of what is shown in a figure, are typically indicated by dashed lines in the drawings.

Further, in the following, embodiments herein are illustrated by exemplary embodiments. It should be noted that these embodiments are not necessarily mutually exclusive. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments.

As a development towards embodiments herein, the situation indicated in the Background will first be elaborated upon.

Another aspect of program errors than from perspective of an end user, is from the perspective of the developer or programmer of the program, or from the perspective of software program testers. These persons of course have both insights and possibilities to understand and get detailed information that is not usually available to the end users of the program. When a program is tested or debugged and an error occurs, the program typically generates what is known as an exception. The exceptions is normally presented as a dialog box displaying a message, for example: Warning! An unhandled exception of type“System. NullReferenceException” occurred in Application 24.exe.

Additional information: Object reference not set to an instance of an object.

OPTIONS: Break Continue Ignore Help

This type of dialog is normally not very useful as such because it is presented out- of-context from the code that generated the exception, making it difficult for the developer to fully understand what went wrong. Also, the choices presented by the dialog are often confusing. It is e.g. not always clear what distinguishes“Continue” from“Ignore”. The “Continue” option can be confusing because when this option is selected, the application may actually shut down. Typically, selecting the“Help” option launches a topic on using the dialog rather than a topic on how to handle the exception. Finally, the content of the dialog itself is parsimonious, confusing and does little to help the developer solve the problem in the code.

It is realized that this kind of information if passed to the end user of the program, which sometimes programs are configured to do, the information would be even less helpful and more confusing.

What would be better is a solution that when an error is detected, would analyze if the error has occurred before, for the same or other users, and then informs the user of error status and workarounds. Error status could e.g. be information on that the error is already known and is currently being corrected or have already been corrected in a newer program versions. A workaround could describe how to solve the task that the faulty function implements, i.e. that was negatively affected by the error. This kind of error management and information would be beneficial both to the end user and anyone working with the development of the program.

As used herein, something that leads to an abnormal termination of a program during its execution is called a program error. When an error occurs, an exception may be generated, or“raised”. For example, an exception may be generated by an arithmetic logic unit or floating-point unit of a processor when an operation such as dividing by zero is detected or when an overflow or underflow condition occurs. An exception may also be generated by trying to execute an undefined instruction, or by privilege violations. A program error may thus correspond to an exception. Figure 1 is a block diagram schematically depicting an example of a computer network 100 in relation to which embodiments herein will be discussed. The shown network has various nodes that are connected to, e.g. as parts of, the computer network 100 and may thus be communicatively connected to each other over, or through, the computer network 100. The computer network 100 may advantageously be the Internet but may be any other computer network, e.g. Internet Protocol (IP) network. As used herein, IP network refers to a data communication network based on, such as

implemented to support, the Internet Protocol, e.g. version 4 or version 6, i.e. IPv4 or IPv6. The nodes may be referred to as network nodes when connected to or part of the computer network. The nodes may be logical and/or physical nodes. In the figure it is shown some nodes corresponding to and exemplified by physical nodes. In particular it is shown and exemplified devices 120a-c, typically user devices, i.e. associated with users, respectively, an error management server 110 and a program provider server 130.

The devices may be data processing devices, e.g. be personal computers, smart phones, or the like, or in principle any kind of computer program executing devices associated with users, respectively. As used herein,‘server’ may refer to a specific computer configured to act as a server and e.g. implement embodiments herein, or it may refer to a server, or server service, provided through or as a so called cloud, or cloud service, configured, or set up, to implement embodiments herein. In case of the cloud, any one that uploads a software that configures or programs the server to act in accordance with embodiments herein may not know which or have access to the physical computer or computers that executes the software since they are“hidden by the cloud”. Even their geographical location may be unknown. However, whoever uploads the software that configures or programs the server to act in accordance with embodiments is typically responsible, e.g. by agreement with a cloud providing legal entity, for the execution of the software. The devices 120a-c, the error management server 110 and the program provider server 130 will be exemplified below when embodiments herein are discussed in some detail.

The shown devices and servers may thus be communicatively connected to each other via the computer network 100, e.g. by being connected to the Internet. When the devices 120a-c communicate with any of the servers 1 10, 130, they may be configured to do so in a secure way, e.g. using a so called Virtual Private Network (VPN) or by other means of data encryption.

It should be understood that the type of user devices mentioned above typically comprise user interfaces, respectively, that allow for different kind of user input and output to the device. The user interface may be of different types, including conventional types for interfacing a user, e.g. display, i.e. screen, that may be touch sensitive, a keyboard, and/or action buttons etc.

Attention is drawn to that Figure 1 is only schematic and for exemplifying purpose and that not everything shown in the figured may be required for all embodiments herein, as should be evident to the skilled person. Also, a communication network, e.g. that correspond(s) to the will typically involve several further network nodes and details, as realized by the skilled person, but which are not shown herein for the sake of simplifying.

Figure 2 depicts a combined signaling diagram and flowchart, which will be used to discuss embodiments herein, in particular methods and actions performed by device, e.g. any one of the devices 120a-c, although device 120a will be used as an example in the following, and by a server, e.g. error management server, e.g. the error management server 1 10.

The methods and actions are for managing a program error of a computer program executed by a device, e.g. the device 120a.

The actions below may be taken in any suitable order and/or be carried out fully or partly overlapping in time when this is possible and suitable.

Action 201

The device 120a detects, during and from execution of the computer program on the device 120a, occurrence of the program error. The detection itself may be based on existing and known principles and e.g. result from that a so called exception occurs in execution of the program. The program error may be detected by the program provider’s own code or by a separate error handling code, e.g. in the form of an error handling library.

Action 202

In some embodiments, the device 120a generates, based on error identifying information, an error identifier identifying the program error.

The error identifying information relates to at least an error type associated with the detected program error and a stack trace associated with the program error. The error identifying information may further relate to information on the computer programming framework that the computer program is based on or is executing as part of, e.g.

ASP.NET Core. The error identifier should identify the program error among other program errors that may occur. The error identifier should be generated so that the same error identifier can, or will, be generated for the same program error even if it occurs at different occasions and e.g. on different devices. For example, the different occasions may be different occasions when the program is executed on the device 120a and/or occasions when the program error occurs during execution of the computer program on other device(s), e.g. on any one of the devices 120b-c. In other words, the identifier may be identifying the program error among other identifiers identifying other program errors that may occur when executing the computer program, where the identifier is independent on the occurrence of the program error, i.e. independent on when the program error occur and on which device. Such identifier has proven possible to generate from e.g. said error type and stack trace.

Moreover, the error identifier is preferably generated from a cleaned version of the error type and the stack trace, in which cleaned version information being irrelevant for said program error identification has been removed. Said irrelevant information is typically relating to the specific occurrence of the program error rather than the program error as such and/or relating to the device as such and/or relating to a version of the computer programming framework that the computer program is based on. Said irrelevant information may e.g. comprise row numbers of the stack trace and/or different code paths in the used programming framework that results in the same error. Thereby e.g. also asynchronous programming can be handled and one and the same program error will more often result in the same error identifier even though the stack traces may differ owing to the asynchronous programming. Cleaning generally facilitates generation of useful error identifiers and reduces the risk that different error identifiers will be generated although the error actually should be regarded the same.

The error type mentioned above may correspond to what typically is referred to as exception type.

The stack trace as mentioned above is a well-known concept in computer programming and is typically made easily accessible in all computer programming frameworks. The stack trace corresponds to an execution path, typically a sequence, of programming code parts that have executed, e.g. a part causing execution of another, next part etc. In the present context the stack trace thus corresponds to a sequence of programming code parts that resulted in the occurrence of the program error. Action 203

The device 120a forms an error report for identification of the program error based on said error identifying information.

In the embodiments where the device 120a generates the error identifier as in Action 202, the error report may comprise the error identifier. In these embodiments, information on error type and stack trace may be excluded from the error report.

In some embodiment, the error report comprises said error identifying information, such as comprises information on the error type and the stack trace, e.g. in embodiments where the identifier is not generated by the device 120a as in the Action 202. Note that the information on the error type and the stack trace may, but need not, be the cleaned version of the error type and/or stack trace as described above. In these embodiments, the identifier may instead be generated by an error management server, e.g. the error management server 110, as will be further described below. Cleaning of the error type and the stack trace may in this case also be performed by the error management server 110. These embodiments may be preferred since it is then easier to make sure that e.g. an algorithm for generating the identifier is one and the same and always an up to date, for example that a latest version will be used for generating error identifiers. It enables a more robust solution.

The error report may also contain further information, in principle any available information that may relate to and may be useful for describing causes of the error, such as http request information or messaging information in micro services architectures.

Action 204

The device 120a may send the error report, via a computer network, e.g. the computer network 100, to an error management server, e.g. the error management server 1 10 that thus may receive the error report. The error management server being configured to receive error reports from one or more devices, e.g. the devices 120a-c, executing the computer program. That is, may receive also other, corresponding error reports regarding the same and other program errors.

Action 205

The error management server 1 10 obtains, based on the received error report, an error identifier identifying the program error. The error identifier may be as discussed above and thus identifies the program error among other program errors that may occur. As already indicated above, in some embodiments that may be preferred, the error management server 110 obtains the error identifier by generating it based on the error identifying information that may be comprised in the error report. The error identifier should be generated so that the same error identifier can, or will, be generated for the same program error even if it has occurred at different occasions and/or on different devices.

In some embodiments, the error identifier is being obtained by receiving it with the error report, e.g. in case it has been generated by the device 120a.

As also already indicated above, the error identifier may be generated from a cleaned version of the error type and the stack trace, and in which cleaned version information being irrelevant for said program error identification has been removed. It may be the device 120a or the error management server 1 10 that performs the cleaning.

Action 206

The error management server 1 10 initiates comparison of the obtained error identifier with previously generated identifiers identifying program errors occurred, i.e. previously, in execution of the computer program on devices, e.g. any of the devices 120a-c, and that have been previously reported by means of other error reports. The previously generated identifiers are further associated with error managing information relating to error status regarding a solution to the program error and/or recommended user actions for managing the program errors identified by the previously generated identifiers, respectively.

The previously generated identifiers may be stored locally and/or remotely from the error management server 1 10, e.g. on another server, such as the program provider server 130 with or without a local copy on the error management server 110. The error managing information may be stored together with the identifiers and/or be retrieved from e.g. the program provider server 130 in case the comparison results in that the error identifier was already“known” i.e. had been generated before. That is, e.g. Action 210 described below may be carried out in response to that the comparison results in that the error identifier already exist, i.e. has been generated before, and the error managing information may then be obtained as in Action 21 1 described below.

In some embodiments, the comparison is performed by the error management server 1 10, in others it may be carried out externally, e.g. by the program provider server 130. In the latter embodiments, the error management server 1 10 may initiate the comparison by sending the error identifier as part of the error information to the program provider server in Action 210, the program provider server 130 may then compare the error identifier to stored, previously generated identifiers and may as in Action 211 send the error managing information to the error management server 1 10.

Action 207

The error management server 1 10 generates a response message based on the comparison and comprising the error managing information, if any, associated with the program error identified by the error identifier.

Action 208

The error management server 1 10 sends the response message to the device 120a via the computer network 100, i.e. in response to the error report received from the device in Action 204. The device 120a may thus, in response to the sent error report, receive the response message from the error management server 1 10 via the computer network 100.

The response message comprises the error managing information, if any, relating to error status regarding a solution to the program error and/or recommended user actions for managing the program error. In case there is no yet any error managing information specific for the error, the response message may be empty regarding such information or may contain some default information for this case.

Action 209

The device 120a may provide, based on the received response message, information, e.g. regarding the error status and/or recommended user actions, directed to a user of the device 120a experiencing the program error. For example, the device may display information, e.g. a pop-up message, with the error status and/or the

recommended user actions. In case there is no yet any error managing specific for the error, the user may be informed about this and/or displayed some default information for this case, e.g. that the error appears new but now is reported and that a solution should be expected shortly. The user may e.g. be offered a possibility to be contacted, e.g. via email, when there is, or is new, error managing information available for the error.

As should be realized, the provided information directed to the user is provided by means of a user interface of the device, such as display and an associated graphical user interface. Action 210

The error management server 1 10 may provide, such as send, e.g. via the computer network 100, error information based on the error report, and other error reports regarding the same program error, or at least with the same error identifier, to a program provider server, e.g. the program provider server 130. That is, to another server that may be controlled or at least accessible by the a provider of the computer program, e.g. the developer and/or programmer and/or team and/or company providing the computer program. The program provider server 130 may accordingly receive the error information.

The error information should at least contain the error identifier but may typically also contain additional information, e.g. the error report or at least relevant information thereof to provide better information basis to the program provider in order to find out how the program error should be managed, e.g. solved, and/or actions to recommend to the user. The error information may thus be considered as information on a program error associated with a particular error identifier.

The first time a program error occurs, the error information contains the first occurrence of the error identifier identifying the program error. The program provider may thereby for the first time be informed about the program error and may start to take action to solve the program error, including to for example involve a software developer or development team, and/or provide error managing information regarding the program error. However, the program provider may wait until the program error has occurred a certain number of times, or at least not just only once, before taking action, e.g. awaiting further occurrences of the program identifier in received error information, just to avoid spending taking action on program errors that e.g. have occurred for random reasons or extremely seldom.

When error information with regard to a program error that already has been reported about in error information is received by the program provider server 130, e.g. the second or further occurrence of a certain error identifier, the error information may be considered to be error update information, i.e. regarding repeated occurrences of the program error.

When an error already has occurred, the program provider may take into account how often and at which frequency the program error occurs, and e.g. in relation to an estimated number of users, and base further actions on that. When error update information is sent, it may be a reduced amount of information sent in the error information in addition to the error identifier as such, if e.g. this additional information would else be the same as already sent, e.g. together with the first occurrence of the error identifier.

Action 211

The error management server 110 may obtain, e.g. receive from the program provider server 130, e.g. via the computer network 100 (updated) error managing information. This may but necessarily be in response to the sent error (update) information. The (updated) error managing information may correspond to the error managing information discussed above and that is sent to the device 120a in the response message of Action 208. That is, the (updated) error managing information may relate to error status and/or recommended user actions for managing the program error. The error managing information is updated error managing information if error managing information about a program error, as identified by a program identifier, has changed, e.g. been updated in some way. Reason may e.g. be that the error status and/or

recommended user actions regarding the program error have changed, e.g. due to that the program error has been solved, a new program version without the program error is available and can be linked to, a new fix or workaround exist, the recommend user actions have changed for some reason etc. The first time error information abut a program error is sent to the program provider, the error managing information may contain some default information about this being a new error and some default recommended user action, i.e. the error managing information may not be regarding a specific solution to the program error since there has been no time yet for such solution to be developed by the program provider. It is thus likely that error managing information regarding a program error will be updated at least once after the program error initially has been reported to the program provider.

In some embodiments, the error management server 1 10 and the program provider server 130 may be implemented as one and the same server. Although the error update information and updated error managing information in this case still may be provided, obtained and used in a corresponding way, it is of course not needed to send and receive over a computer network. However, there may be advantages related with separate servers. For example may the actions and functionality of the servers be associated with different requirements both in terms of the number of connections, availability, uptime, response time etc. It may also be legal and proprietary issues if a single server is used if it is desirable to support multiple software programs from different program providers, e.g. from different companies and that even may be competitors.

It should be noted that although Actions 210-211 in Figure 2 are shown subsequent to Action 207, error managing information may be obtained in Action 211 before Action 207 is carried out so that any existing error manging information, updated or not, can be included in the response message, and preferably without the need to request it from the program provider server 130 each time.

Figures 3a-c show example of how a device experiencing a program error, e.g. the device 120a, may provide information regarding error status and/or recommended user actions directed to the user. In the shown examples a pop-up window with the information is displayed to the user.

Figure 3a is an example of a pop-up window that may be used notwithstanding embodiments herein and for example when a program error is new and/or not known to have occurred before, e.g. when there is not yet any error managing information to display. This is thus a pop-up window that is typically not based on error managing information as in Actions 208-209. This information may e.g. be determined to be shown as long as there has not yet been any investigation of the program error, and e.g. when there is not yet any information what have caused the program error or any specific information about the program error to display. This pop-up may be temporarily shown and then be replaced, e.g. when there is more information known about the program error.

Figure 3b is another example of a pop-up window, in this case one that may be displayed when an error is already known, e.g. since it has occurred before, or after a new error has been investigated, but not yet been corrected, and may then e.g. replace the pop-up in Figure 3a. Also this pop-up may thus be temporarily shown and then be replaced, e.g. when there is more information about the program error, e.g. when the program error has been corrected. The shown information about workaround is optional, and additional or alternative information may be shown if more suitable. The information in this pop-up may e.g. be based on error managing information as in Actions 208-209.

Figure 3c is yet another example of a popup window, in this case one that may be displayed when an encountered program error has been corrected, e.g. since it has occurred before and a fix already exists, or after some time when the program error has been fixed and may then e.g. replace the pop-up in Figure 3b. The download via the URL as shown in the figure is only an example, additional or alternative information for accessing a correction to the program error may be provided. The information in this pop up may e.g. be based on error managing information as in Actions 208-209 and may e.g. originate from the program provider and/or a developer team that has corrected the program error.

As realized from the above, embodiments herein enable to provide more up to date, useful and relevant information about a program error to a user encountering the program error compared to what conventionally is possible, e.g. up to date information on error status and workarounds, and this can be done in an automated fashion directly in the program and/or information technology system being used. Thereby users do not have to manually search for error information, contact the support or trying to figure out how they can carry on, despite the program error, to solve the task that was the reason they used the program that resulted in the program error.

Embodiments herein are further compatible with and may be integrated with different types of programming frameworks, as should be realized by the skilled person.

Figure 4 is a schematic block diagram for illustrating embodiments of a device, e.g. the device 120a, may be configured to perform a method based on actions performed by the device 120a as discussed above in relation to Figure 2.

Hence, the device 120a is for managing a program error of a computer program executed by the device 120a.

The device 120a may comprise processing module(s) 401 , such as a means, one or more hardware modules, including e.g. one or more processors, and/or one or more software modules for performing said method and/or actions.

The device 120a may further comprise memory 402 that may comprise, such as contain or store, a computer program 403. The computer program 403 comprises 'instructions' or 'code' directly or indirectly executable by the device 120a to perform said method and/or actions. Note that the computer program 403 should be another or separate computer program than the computer program of the program error, although they may be fully or partly integrated. The memory 402 may comprise one or more memory units and may further be arranged to store data, such as configurations and/or applications involved in or for performing functions and actions of embodiments herein.

Moreover, the device 120a may comprise processing circuit(s) 404 as

exemplifying hardware module(s) and may comprise or correspond to one or more processors. In some embodiments, the processing module(s) 401 may comprise, e.g.‘be embodied in the form of or‘realized by’ the processing circuit(s) 404. In these

embodiments, the memory 402 may comprise the computer program 403 executable by the processing circuit(s) 404, whereby the device 120a is operative, or configured, to perform said method and/or actions.

Typically the device 120a, e.g. the processing module(s) 401 , comprises

Input/Output (I/O) module(s) 405, configured to be involved in, e.g. by performing, any communication to and/or from other devices and/or servers, e.g. via a computer network, e.g. the computer network 100, such as sending and/or receiving information. The I/O module(s) 405 may be exemplified by obtaining, e.g. receiving, module(s) and/or providing, e.g. sending, module(s), when applicable.

Further, the device 120a typically comprises a user interface 406, that may be integrated with the device 120a and/or be communicatively connected to it. The user interface 406 allows for different kind of user input and output to/from the device 120a. The user interface 406 may comprise different type of interfaces for communications with a user of the device, including any conventional type for interfacing a user, e.g. a display, i.e. screen, that may be touch sensitive, a keyboard, action buttons, loudspeaker, and/or microphone e.g. allowing for communication using voice recognition etc. As realized the user interface 406, when including a display or screen, is typically associated with a graphical user interface.

Further, in some embodiments, the device 120a, e.g. the processing module(s) 401 , comprises one or more of detecting module(s), forming module(s), sending module(s), generating module(s), receiving module(s), providing module(s), as exemplifying hardware and/or software module(s). These modules may be fully or partly implemented by the processing circuit(s) 404.

Hence:

The device 120a, and/or the processing module(s) 401 , and/or the processing circuit(s) 404, and/or the I/O module(s) 405, and/or the detecting module(s) may be operative, or configured, to detect said occurrence of the program error as described above in connection with Figure 2.

Further, the device 120a, and/or the processing module(s) 401 , and/or the processing circuit(s) 404, and/or the forming module may be operative, or configured, to form said error report as described above in connection with Figure 2.

Moreover, the device 120a, and/or the processing module(s) 401 , and/or the processing circuit(s) 404, and/or the I/O module 405, and/or the sending module may be operative, or configured, to send the error report, as described above in connection with Figure 2, to the error management server 110.

Also, the device 120a, and/or the processing module(s) 401 , and/or the processing circuit(s) 404, and/or the generating module may be operative, or configured, to generate the error identifier as described above in connection with Figure 2.

Furthermore, the device 120a, and/or the processing module(s) 401 , and/or the processing circuit(s) 404, and/or the I/O module 405, and/or the receiving module may be operative, or configured, to receive the response message, as described above in connection with Figure 2, from the error management server 110.

Additionally, the device 120a, and/or the processing module(s) 401 , and/or the processing circuit(s) 404, and/or the I/O module 405, and/or the user interface 406, and/or the providing module may be operative, or configured, to provide said information directed to the user, as described above in connection with Figure 2.

Figure 5 is a schematic block diagram for illustrating embodiments of a server, e.g. the error management server 110, may be configured to perform a method based on actions performed by the error management server 1 10 as discussed above in relation to Figure 2.

Hence, the error management server 110 is for managing a program error of a computer program executed by the device 120a.

The error management server 1 10 may comprise processing module(s) 501 , such as a means, one or more hardware modules, including e.g. one or more processors, and/or one or more software modules for performing said method and/or actions.

The error management server 1 10 may further comprise memory 502 that may comprise, such as contain or store, a computer program 503. The computer program

503 comprises 'instructions' or 'code' directly or indirectly executable by the error management server 1 10 to perform said method and/or actions. Note that the computer program 503 should be another or separate computer program than the computer program of the program error. The memory 502 may comprise one or more memory units and may further be arranged to store data, such as configurations and/or applications involved in or for performing functions and actions of embodiments herein.

Moreover, the error management server 110 may comprise processing circuit(s)

504 as exemplifying hardware module(s) and may comprise or correspond to one or more processors. In some embodiments, the processing module(s) 501 may comprise, e.g.‘be embodied in the form of or‘realized by’ the processing circuit(s) 504. In these embodiments, the memory 502 may comprise the computer program 503 executable by the processing circuit(s) 504, whereby the error management server 1 10 is operative, or configured, to perform said method and/or actions.

Typically the error management server 110, e.g. the processing module(s) 501 , comprises Input/Output (I/O) module(s) 505, configured to be involved in, e.g. by performing, any communication to and/or from other devices and/or servers, e.g. via a computer network, e.g. the computer network 100, such as sending and/or receiving information. The I/O module(s) 505 may be exemplified by obtaining, e.g. receiving, module(s) and/or providing, e.g. sending, module(s), when applicable.

Further, in some embodiments, the error management server 1 10, e.g. the processing module(s) 501 , comprises one or more of receiving module(s), obtaining module(s), initiating module(s), generating module(s), sending module(s), as exemplifying hardware and/or software module(s). These modules may be fully or partly implemented by the processing circuit(s) 504.

Hence:

The error management server 110, and/or the processing module(s) 501 , and/or the processing circuit(s) 504, and/or the I/O module(s) 505, and/or the receiving module(s) may be operative, or configured, to receive the error report, as described above in connection with Figure 2, from the device 120a.

Further, the error management server 110, and/or the processing module(s) 501 , and/or the processing circuit(s) 504, and/or the I/O module(s) 505, and/or the obtaining module may be operative, or configured, to obtain the error identifier as described above in connection with Figure 2.

Moreover, the error management server 110, and/or the processing module(s) 501 , and/or the processing circuit(s) 504, and/or the I/O module 505, and/or the initiating module may be operative, or configured, to initiate the comparison, as described above in connection with Figure 2.

Also, the error management server 1 10, and/or the processing module(s) 501 , and/or the processing circuit(s) 504, and/or the generating module may be operative, or configured, to generate the response message as described above in connection with Figure 2.

Furthermore, the error management server 110, and/or the processing module(s) 501 , and/or the processing circuit(s) 504, and/or the I/O module 505, and/or the sending module may be operative, or configured, to send the generated response message, as described above in connection with Figure 2, to the device 120a. Figure 6 is a schematic drawing illustrating some embodiments relating to computer programs and carriers thereof to cause said device 120a and error management server 1 10, discussed above, to perform said methods and actions. The computer programs may be the computer programs 403, 503 and comprises instructions, respectively, that when executed by the processing circuit(s) 404, 504 and/or the processing module(s) 401 , 501 causes the device 120a and the error management server 1 10 to perform as described above. In some embodiments there is provided carriers, or more specifically a data carriers, e.g. computer program products, respectively, comprising one or more of the computer programs 403, 503. Each carrier may be one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium, e.g. a computer readable storage medium 601 as schematically illustrated in the figure. The computer programs 403, 503 may thus be stored on the computer readable storage medium 601 , alone or in combination. By carrier may be excluded a transitory, propagating signal and the data carrier may correspondingly be named non-transitory data carrier. Non-limiting examples of the data carrier being a computer readable storage medium is a memory card or a memory stick, a disc storage medium such as a CD or DVD, or a mass storage device that typically is based on hard drive(s) or Solid State Drive(s) (SSD). The computer readable storage medium 601 may be used for storing data accessible over a computer network 602, e.g. the Internet or a Local Area Network (LAN). The computer network 602, may fully or partly correspond to the computer network 100. The computer programs 403, 503 may furthermore be provided as pure computer program(s) or comprised in a file or files. The file or files may be stored on the computer readable storage medium 601 and e.g. available through download e.g. over the computer network 602 as indicated in the figure, e.g. via a server that may be a complete different server than other servers discussed herein, e.g. the error management server 110. The server may e.g. be a web or File Transfer Protocol (FTP) server. The file or files may e.g. be executable files for direct or indirect download to and execution on said device 120a and error management server 110, respectively, to make each perform as described above, e.g. by execution by the processing circuit(s) 404, 504. The file or files may also or alternatively be for intermediate download and compilation involving the same or another processor to make them executable before further download and execution causing said device 120a and/or error management server 1 10 to perform as described above. Note that any processing module(s) and circuit(s) mentioned in the foregoing may be implemented as a software and/or hardware module, e.g. in existing hardware and/or as an Application Specific Integrated Circuit (ASIC), a field-programmable gate array (FPGA) or the like. Also note that any hardware module(s) and/or circuit(s) mentioned in the foregoing may e.g. be included in a single ASIC or FPGA, or be distributed among several separate hardware components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

Those skilled in the art will also appreciate that the modules and circuitry discussed herein may refer to a combination of hardware modules, software modules, analogue and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in memory, that, when executed by the one or more processors may make the node(s) and device(s) to be configured to and/or to perform the above-described methods and actions.

Identification by any identifier herein may be implicit or explicit. The identification may be unique in a certain context, e.g. for a certain computer program or program provider.

As used herein, the term "memory" may refer to a data memory for storing digital information, typically a hard disk, a magnetic storage, medium, a portable computer diskette or disc, flash memory, Random Access Memory (RAM) or the like. Furthermore, the memory may be an internal register memory of a processor.

Also note that any enumerating terminology such as first node, second node, first base station, second base station, etc., should as such be considered non-limiting and the terminology as such does not imply a certain hierarchical relation. Without any explicit information in the contrary, naming by enumeration should be considered merely a way of accomplishing different names.

As used herein, the expression "configured to" may mean that a processing circuit is configured to, or adapted to, by means of software or hardware configuration, perform one or more of the actions described herein.

As used herein, the terms "number" or "value" may refer to any kind of digit, such as binary, real, imaginary or rational number or the like. Moreover, "number" or "value" may be one or more characters, such as a letter or a string of letters. Also, "number" or "value" may be represented by a bit string.

As used herein, the expression“may” and "in some embodiments" has typically been used to indicate that the features described may be combined with any other embodiment disclosed herein. In the drawings, features that may be present in only some embodiments are typically drawn using dotted or dashed lines.

As used herein, the expression "transmit" and "send" are typically interchangeable. These expressions may include transmission by broadcasting, uni-casting, group-casting and the like. In this context, a transmission by broadcasting may be received and decoded by any authorized device within range. In case of unicasting, one specifically addressed device may receive and encode the transmission. In case of group-casting, e.g.

multicasting, a group of specifically addressed devices may receive and decode the transmission.

When using the word "comprise" or "comprising" it shall be interpreted as nonlimiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the above described embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the present disclosure, which is defined by the appending claims.