Projekt

Allgemein

Profil

« Zurück | Weiter » 

Revision fbc8b548

Von G. Richardson vor fast 5 Jahren hinzugefügt

  • ID fbc8b54802ceaec680e0c86a7ac99dfd286848d8
  • Vorgänger 00bad502
  • Nachfolger 3bd31e0d

Typos in DB.pm POD

Unterschiede anzeigen:

SL/DB.pm
222 222

  
223 223
=item Error handling
224 224

  
225
The original L<Rose::DB/do_transaction> gobbles up all execptions and expects
226
the caller to manually check return value and error, and then to process all
227
exceptions as strings. This is very fragile and generally a step backwards from
228
proper exception handling.
225
The original L<Rose::DB/do_transaction> gobbles up all exceptions and expects
226
the caller to manually check the return value and error, and then to process
227
all exceptions as strings. This is very fragile and generally a step backwards
228
from proper exception handling.
229 229

  
230
C<with_transaction> only gobbles up exception that are used to signal an
230
C<with_transaction> only gobbles up exceptions that are used to signal an
231 231
error in the transaction, and returns undef on those. All other exceptions
232 232
bubble out of the transaction like normal, so that it is transparent to typoes,
233 233
runtime exceptions and other generally wanted things.
234 234

  
235 235
If you just use the snippet above, your code will catch everything related to
236 236
the transaction aborting, but will not catch other errors that might have been
237
thrown. The transaction will be rollbacked in both cases.
237
thrown. The transaction will be rolled back in both cases.
238 238

  
239 239
If you want to play nice in case your transaction is embedded in another
240 240
transaction, just rethrow the error:

Auch abrufbar als: Unified diff