[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