Ho to spare a Pharo desktop application user from seeing the debugger?
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. -- 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.
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.
Not unreasonable. What if you are out of memory? Can you restart? Exception is fine at the highest level. 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.
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.
First, thank you for your answers, Igor and Cameron. Igor Stasenko wrote
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 :)
My application does parse a lot of files and does some number-crunching with them. As the user can in theory include as many files as she wants in these calculations, i suppose there might very well be a moment, when memory is not enough. So you say, there is no way to stop things before it is too late (not enough memory)? -- 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.
On 18 April 2013 17:04, MartinW <wm@fastmail.fm> wrote:
First, thank you for your answers, Igor and Cameron.
Igor Stasenko wrote
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 :)
My application does parse a lot of files and does some number-crunching with them. As the user can in theory include as many files as she wants in these calculations, i suppose there might very well be a moment, when memory is not enough. So you say, there is no way to stop things before it is too late (not enough memory)?
if there's not enough memory, you should receive OutOfMemory exception. (or hard crash ;) but why asking? try by yourself.
-- 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.
may be you should count a bit the memory that it takes for some samples and do some prediction and count how many entities you can get and monitor them? Stef On Apr 18, 2013, at 5:04 PM, MartinW <wm@fastmail.fm> wrote:
First, thank you for your answers, Igor and Cameron.
Igor Stasenko wrote
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 :)
My application does parse a lot of files and does some number-crunching with them. As the user can in theory include as many files as she wants in these calculations, i suppose there might very well be a moment, when memory is not enough. So you say, there is no way to stop things before it is too late (not enough memory)?
-- 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.
On 18 April 2013 21:23, stephane ducasse <stephane.ducasse@free.fr> wrote:
may be you should count a bit the memory that it takes for some samples and do some prediction and count how many entities you can get and monitor them?
SpaceTally is your friend :)
Stef
On Apr 18, 2013, at 5:04 PM, MartinW <wm@fastmail.fm> wrote:
First, thank you for your answers, Igor and Cameron.
Igor Stasenko wrote
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 :)
My application does parse a lot of files and does some number-crunching with them. As the user can in theory include as many files as she wants in these calculations, i suppose there might very well be a moment, when memory is not enough. So you say, there is no way to stop things before it is too late (not enough memory)?
-- 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.
participants (4)
-
Cameron Sanders -
Igor Stasenko -
MartinW -
stephane ducasse