[Digikam-users] [Feature Request] Catch crashes in third party subsystems and handle them inside digikam
Peter Albrecht
peter at crazymonkeys.de
Wed Jun 4 20:34:24 BST 2014
Hello mailing-list,
I totally agree with Nicolas and Jim: Error-management is
difficult, but enhances software stability a lot.
Of course someone must be found, doing this job. ;)
Maybe one of you, Jim or Nicolas, could file a feature
request at https://bugs.kde.org/ and post the link in this list.
Then people could start voting for it. And it will remain in
TODO-lists longer than just three mails in the mailing list.
Regards,
Peter
On 03.06.2014 07:11, Nicolas MF wrote:
> Sorry to catch up a little late on this. I don't know how much work this
> request would mean, or even if it is feasible in this case (I mean proper
> handling). Dying gracefully would still be better than silent hara-kiri.
>
> I think it is a great feature request. Of course, things have to get
> patched and work, eventually. But as digikam, and most OSS, relies heavily
> on other components, this will happen over and over again. "Protecting"
> your digikam session against such events is a huge step forward in terms of
> robustness.
>
> Nicolas Martinez
>>
>> 2014-05-24 4:49 GMT+02:00 James R. Shipman <JimShip at sbcglobal.net>:
>>> Digikam as currently designed is vulnerable to crashes in third party
>>> subsystems. This has showed up strongly with the current problems with
>>> sqlite and exiv2 where digikam simply dies every time one of its
>> subsystem
>>> crashes.
>>>
>>> I would suggest that a better way would be to catch these crash events
>> and
>>> either handle them (for example skip a file that caused exiv2 to crash)
>> or
>>> at least to die gracefully.
>>>
>>> Not doing this causes digikam to suffer in its reputation and in the
>> worst
>>> case to make it unusable. Right now when I start digikam and just let
>> it be
>>> idle, then a few minutes later it simply disappears. Crashing while
>> scanning
>>> metadata in the background. I have been trying to filter out the
>> offending
>>> files (*.MTS files in my case), but I have to be fast because while I'm
>>> trying to change digikam settings (filter out mts type) it will still
>> crash
>>> causing me to have to start all over. This is really bad behavior.
>>>
>>> Jim Shipman
>>> _______________________________________________
>>> Digikam-users mailing list
>>> Digikam-users at kde.org
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>> _______________________________________________
>> Digikam-users mailing list
>> Digikam-users at kde.org
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
>
>
>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>
More information about the Digikam-users
mailing list