On 15 April 2013 00:39, Cameron Sanders <camsanders@aol.com> wrote:
Not unreasonable. What if you are out of memory? Can you restart? Exception is fine at the highest level.
well, most programs pay little attention on consumed resources. and usually there is no monitoring for consumption. when you meet such situation, usual behavior is crash with sound of thousands of breaking glasses :)
I recommend employing [] on: Error do: [] at various intermediate to high levels of application code -- as distinguished from "library" level objects and packages.
At application level, trapping Errors (in bulk!) can lead to much cleaner fault-tolerant code without branching for the dozens of reasons something could fail. And then tabulate those errors and present them (electively) for the user... or to a system log-file.
-Cam
On Sat, Apr 13, 2013 at 2:56 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 April 2013 18:41, MartinW <wm@fastmail.fm> wrote:
I deploy a Pharo desktop application and i want to spare the user from seeing the debugger, because most users would not know what to do with it.
My solution for the moment is to place an [] on: Exception do: [] around my application's entrance point: [ "main application workflow" ] on: Exception do: [ self inform: 'Something has gone wrong...'. "and restart application"]
Do you think, this an acceptable solution? Are there others? M.
Fairly acceptable. You need to handle error condition in one way or another, if you don't wanna show debugger to user.
But if your application spawns multiple threads, then it will still pop up debugger if error will happen in one of those threads (unless of course you also wrap everything with exception handler).. actually handling unexpected (exceptional) cases is a good practice :)
-- View this message in context: http://forum.world.st/Ho-to-spare-a-Pharo-desktop-application-user-from-seei... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.