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.
>

> 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 <[hidden email]> wrote:
>>
>> On 13 April 2013 18:41, MartinW <[hidden email]> 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-seeing-the-debugger-tp4681254.html
>> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>> >
>>
>>
>>
>> --
>> 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)?
>

> 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-seeing-the-debugger-tp4681254p4682335.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

> Stef
>
> On Apr 18, 2013, at 5:04 PM, MartinW <[hidden email]> 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-seeing-the-debugger-tp4681254p4682335.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>
>
>